Release #2

The code for release #2 has been tagged in the BitBucket repository. You can download the software distribution and check it out for yourself.

Features Complete:

  • Create database models and diagrams in JavaScript using a domain specific language built using the Fluent Interface Pattern.
  • Interact with models and diagrams through a command-line REPL.
  • The tool will generate a DDL script for database creation for a particular database platform (SQLite3 implemented).
  • The tool will create an initial database diagram based on a database model and can save the diagram to a JavaScript file.
  • Models and diagrams can be split up among multiple JavaScript files.

Demonstration:

Retrospective:

Actual Hours Worked by Day

I spent just over 60 hours working on the code for this project over the past semester. This equates to about 1.5 work-weeks of effort had I been doing this as a full-time job rather than a “spare-time” project. I feel pretty good about what I’ve been able to accomplish in the amount of time spent. I think the software represents a strong, functional prototype, which is probably all you can expect from a single person in 1.5 work-weeks.

Burndowns for One-week SprintsSince my one-week sprints were more successful than my two-week sprints, I thought I’d compare the burndown charts of the one-week sprints to see if any patterns emerged. The sprints had different amounts of work scoped, so I displayed the burndowns in terms of percent complete. No pattern jumps out at me, though. Each sprint seems pretty unique.


Personal Scrum

If you’ve been following my blog, you know that I have been using an adaptation of Scrum for a one-person team to manage my graduate project. I (and others) call this “Personal Scrum.” The semester-long experience was very positive. The Personal Scrum methodology was an excellent tool to get the work done.

Personal Scrum Definition:

Personal Scrum is an Agile methodology that adapts and applies Scrum practices to one-person projects. It promotes personal productivity through observation, adaptation, progressive elaboration, prioritizing and sizing work, and time-boxing.

Personal Scrum vs. Scrum:

Let’s compare aspects of Scrum as defined by the Scrum Alliance to those of Personal Scrum.

Scrum’s 3 Roles:

A Scrum team has three roles: Product Owner, Scrum Master, and Team Member. The Product Owner is responsible for the business value of the product and decides what is built. The Scrum Master is primarily a facilitator and enforcer of the Scrum rules. The Team is self-organizing and cross-functional. The Team decides how to build what the Product Owner wants and goes about doing it.

Obviously, since Personal Scrum is a methodology for one-person teams, one person must fulfill all three Scrum roles. This is not as difficult as it may sound, because Scrum’s ceremonies typically focus on one role’s responsibilities at a time.

Scrum’s 4 Ceremonies:

The Scrum Alliance lists four ceremonies (think “group activities”) used in Scrum: Sprint Planning, Daily Scrums, Sprint Reviews, and Sprint Retrospectives. Mysteriously missing from this list is Release Planning, perhaps because it is typically not a regularly scheduled event. Exactly what these ceremonies entails is beyond the scope of this blog post, but each of these ceremonies are reflected in some way in the Personal Scrum methodology. I used blog postings for sprint planning, sprint reviews, and sprint retrospective. I tracked my daily work and release plans in Excel. It is important to observe and delineate these activities.

Scrum’s 3 Artifacts:

The Scrum Alliance lists three artifacts used in Scrum: Product Backlog, Sprint Backlog, and Burndown Chart. Each of these artifacts are used in exactly the same manner in Personal Scrum.

My Experience:

  • Initially, I thought I could accomplish way more in one semester than I was actually able to undertake. The Personal Scrum techniques helped me to focus on the most important work first. Velocity tracking and release planning helped me to identify early on that I was unlikely to finish all that I had started out to do. I was able to revise my goals and plan accordingly.
  • I found that estimating work in terms of time is exceptionally hard, especially when you have no team members to help and few of your tasks are similar. I learned to expect my time estimates to be wrong.
  • Estimating in story points is easy and effective.
  • I tried one-week and two-week sprints. For me, one-week sprints were much more effective. One-week sprints have smaller scope. The shorter-term deadlines made the goals and tasks more salient. I found myself to be more diligent on the one-week sprints. The downside to one-week sprints is that you spend a greater percentage of your available time on planning and reporting; less time is available for actually doing the work.
  • Burndown charts have to be done in terms of estimated hours of work accomplished rather than story points. One person is unlikely to finish more than a couple of user stories per one-week sprint. Burn down hours only when a task has been fully finished (“done done”).
  • Use story points to track velocity. Use velocity to do release planning. Release planning is a great way to project what you are likely to be able to accomplish by a certain date (the end of a semester for instance).
  • Committing to posting your sprint plans, demonstrations, retrospectives, and burndown charts online is a great way to keep motivated and accountable. I found this to be an even greater source of motivation than having a faculty advisor. If you know your work is going to be visible in a very public way, you will be more likely to do your best work.

My Work:

The entire project has been chronicled in the materials below. To my knowledge, this is the first fully documented instance of a Personal Scrum project, and it is certainly the most open. My code has been released under the MIT License, and the Excel workbooks and blog posts are released under the Creative Commons Attribution-ShareAlike 3.0 Unported License.


The Four Essential Product Owner Qualities

  1. Informed

    It is imperative that the person in the Product Owner role have a firm understanding of the business processes and needs that are being addressed by the software to be built. A newbie to the business would not be a wise choice for the Product Owner role. A subject matter expert would be a better choice. A person that not only has intimate knowledge of the business but can also teach others well is necessary. The Product Owner has to be able to explain the business to the scrum team. Because the Product Owner is responsible for the project’s return on investment, he or she needs to be well enough informed that they can judge the business value of each user story.
  2. Empowered

    Like George Bush, the Product Owner must be the “decider,” empowered to make the call when questions arise. The Product Owner is the one person on a Scrum project that gets to decide what is built (but not how it is built). One cannot hold a Product Owner responsible for a project’s return on investment without also granting that person the authority to make decisions that impact the ROI. Furthermore, having one person designated to make decisions can greatly improve a project’s velocity. If developers have to convene, address, and negotiate with some sort of council or project steering group each time a decision needs to be made, the scrum team will have difficulty removing roadblocks efficiently.
  3. Available

    The Product Owner role is a full-time job. The person serving in the role should be dedicated to the project. The Product Owner must be available to explain business concepts, processes, and needs to developers when questions come up. When decisions need to be made, the Product Owner must be ready to decide. When features need to be demonstrated and approved, the Product Owner must be available.  Whenever a scrum team has to wait on Product Owner, the team’s velocity is negatively affected and money/time is wasted.
  4. Prepared

    Between explaining, deciding, and approving, the Product Owner must be busy grooming the product backlog and release plan. Without a properly prepared backlog, a sprint planning meeting is a non-starter. An unprepared Product Owner can be the biggest source of delay to a scrum team. The Product Owner has an obligation to be ready prior to each sprint’s planning meeting so that the team can begin the sprints on the right foot.

EE616 Release Plan Revised

Release planning is one of the major functions of the Product Owner role in Scrum. While sprint planning addresses only the next sprint, release planning is a more strategic, longer-term planning exercise that considers many sprints. The goal of a release plan is to group the product backlog into like-sized sprints based on story points and team velocity. Each sprint should contain topographically similar stories. Each sprint’s theme describes the goal of the sprint. A release plan lays out sprints chronologically and groups them into releases. A release may consist of one or more sprints at the end of which the software is released to the customer. Note that this does not mean that the each sprint should not still result in potentially shippable code, just that the plan for actually shipping code is at the end of the release.

It is important to note that, like the product backlog, the release plan is a living document meant to be revised as you go. The release plan is not the same as a traditional project schedule like you would see on a waterfall project, nor is it a work breakdown structure. It is a tentative, high-level plan for future sprints.

On a personal scrum project, you have to play all the scrum roles – product owner, scrum master, and team. In fact, for this project, I am the customer as well. Last weekend, I revisited and revised my release plan for my graduate project. This was necessary for a number of reasons, not the least of which being my switch from one-week sprints to two-week sprints. I had been grooming my product backlog throughout the first six sprints, and my release plan had become out-of-date.

My original release plan included a second release on March 5th, and a final release on April 22. March 5 would have fallen smack in the middle of a 2-week sprint. I decided to do away with the second release and just have one final release on April 22. This gives me 4 more 2-week sprints between now and the final release. In this time, I will focus heavily on database diagramming via the GUI tool. The scopes for sprints 7, 8, and 9 are pretty well firmed up, having around 16 story points each. I have way too many features left over to get done in sprint 10. As I get closer to sprint 10, I will decide what to include and what to throw out.

I have been doing all of my scrum work in Excel 2010, which has been perfect for personal scrum. I have been posting my product backlog, sprint plans, burndowns, etc. to my project’s BitBucket repository. I have posted my new release plan there as well, and I have released it under the Creative Commons Attribution-ShareAlike 3.0 Unported License. So, feel free to use and adapt it per the license constraints.

The release plan uses the Sparklines feature in Excel 2010 to draw the burndown in each sprint. If you use an older version of Excel, you won’t see these.

Release 1 – Completed

  • Sprint 1 Project Setup + Core Library
  • Sprint 2 Model API
  • Sprint 3 Refactoring + DDL Generation
  • Sprint 4 Refactoring
  • Sprint 5 DDL Generation

Release 2 – April 22

  • Sprint 6 Cmd Line Options + Diagram Viewing
  • Sprint 7 Diagram Creation & Storage + GUI Niceties
  • Sprint 8 Diagram Editing
  • Sprint 9 Diagram Export + Model Explorer + Database Compare
  • Sprint 10 ?

 


Sprint #6 Demo and Retrospective

Burndown Chart:

Sprint #6 Burndown

A classic stair-stepped burndown chart – rather than work a little each day, I was only able to work on the project in bursts. I’ve been quite busy of late. Luckily, as you can see from the green line, I was able to complete the allotted work in less time than I estimated.

Completed User Stories:

  • #19 – A Data Architect needs to be able to view diagrams of a model in a GUI.
  • #12 – Diagram definitions should be stored in a human-readable text format.

Completed Tasks:

  • Integrate the Processing library into the project and build file.
  • Integrate Apache Commons CLI library into the project and build file.
  • Have the main class use command line options to either spawn a REPL or pop a Swing GUI
  • Design a JavaScript API to describe a database diagram
  • Have the GUI read the JavaScript diagram file and the model file.
  • Draw tables in the GUI with Processing
  • Draw foreign key relationships in the GUI with Processing

Technical Debt:

For some inexplicable reason, the application fails to run from the command line or from Ant. As near as I can tell my classpath is set correctly, but Java complains about not finding a class in the Apache Commons CLI library that I am using. When I open the jar file, it is right where it should be. The application runs fine from my IDE. Puzzling…

Demonstration:

Demo Screenshot

Diagram displayed in Java AWT Frame using Processing

Retrospective:

Estimated vs. Actual Hours by Sprint

I estimated the Sprint 6 to take 13 hours of effort using PERT analysis. I was able to complete my work in just over 9 hours. Things are going well. I am on track.

 

 


Sprint #6 Planning

Sprint #6 will be my first two-week sprint. My goal for this sprint is to create a GUI that will display (read-only) database diagrams. Each story is 5 story points and I estimate the tasks to take 13 hours, which should be about right for a two-week sprint.

User Stories:

  • #19 - A DA needs to be able to view diagrams of a model in a GUI.
  • #12 - Diagram definitions should be stored in a human-readable text format.

Tasks:

  • Integrate the Processing library into the project and build file.
  • Integrate Apache Commons CLI library into the project and build file.
  • Have the main class use command line options to either spawn a REPL or pop a Swing GUI
  • Design a JavaScript API to describe a database diagram
  • Have the GUI read the JavaScript diagram file and the model file.
  • Draw tables in the GUI with Processing
  • Draw foreign key relationships in the GUI with Processing

Sprint #5 Demo and Retrospective

Burndown Chart:

Sprint #5 Burndown Chart

Completed User Stories:

  • #5 - The tool should automatically generate DDL for a particular platform based on the model.
  • #18 - Prepare and deliver Release #1

Completed Tasks:

  • Create code to generate DDL for a SQLite database
  • Create tests scripts to test DDL generation
  • Create a demo video
  • Do a release review post.

Technical Debt:

No new technical debt.

Demonstration:

See the Release #1 post.

Retrospective:

I think using PERT analysis will be a helpful tool for estimation moving forward. At minimum, the exercise of picking an optimistic, likely, and pessimistic estimate for each task forces me to consider the estimates more thoroughly.


Sprint #5 Planning

Sprint #5 will be the last sprint for Release #1. I hope to get DDL generation working and ready to demo. I have to deliver something on Friday for class to show progress. So, I will have one less day this sprint to get the work done.

I used PERT analysis to do my estimation this time. It is an estimated 6.5 hours of work.

User Stories:

  • #5 – The tool should automatically generate DDL for a particular platform based on the model.
  • #18 – Prepare and deliver Release #1

Tasks:

  • Create code to generate DDL for a SQLite database
  • Create tests scripts to test DDL generation
  • Create a demo video
  • Do a release review post

Sprint #4 Demo and Retrospective

Burndown Chart:

Sprint #4 Burndown Chart

Completed User Stories:

Technically, none this sprint.

Incomplete User Stories:

  • #17 - Refactor the core library. Separate Fluent API from data structures. Comment and unit test code. (All but unit testing has been completed.)

Completed Tasks:

  • Integrate JUnit into the project and build file.
  • Comment the core library
  • Make the build file create the javadocs

Incomplete Tasks:

  • Write unit tests for the core library

Technical Debt:

No additional technical debt was incurred this sprint.

Demonstration:

There isn’t anything exciting to demo this week. The code has been tagged “sprint4” on BitBucket. If you clone and build the project you can view the generated JavaDocs.

Retrospective:

I spent 5.5 hours on the project this week, which is as much time as I had allocated. Unfortunately, I overestimated how much I could accomplish in 5.5 hours. Estimation has been a constant struggle. In a team-based Scrum planning meeting, the entire team would help estimate each story/task. In a Personal Scrum, obviously, estimation depends on one person. My advisor suggested I try using PERT analysis for estimation. I will try that for Sprint #5 and see if I do any better.


Sprint #4 Planning

I have learned my lesson – there is only so much I can tackle in one week’s free time. Last week I was only able to devote about 5 hours to the project. This week I will target one of the incomplete user stories from last week. The part of the user story that was unfinished equates to 4 tasks and an estimated 5.25 hours effort. On Thursday, there is an Agile Birmingham meeting, and I have class on Friday and Saturday, so there will be less time available this week anyway.

User Stories:

  • #17 - Refactor the core library. Separate Fluent API from data structures. Comment and unit test code.

Tasks:

  • Integrate JUnit into the project and build file.
  • Write unit tests for the core library.
  • Comment the core library.
  • Make the build file create the Java docs.

Follow

Get every new post delivered to your Inbox.