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.


Sprint #9 Demo and Retrospective

Burndown Chart:

Sprint #9 Burndown Chart

Completed User Stories:

  • #30 – Users should be able to run the application from the command line.
  • #31 – Users should be able to split the model and diagram into multiple files

Completed Tasks:

  • Modify the Ant build file to create an “uberjar” of all the libraries
  • Modify the project & Ant build file to put each library’s license into the distribution
  • Solve the classloader problem preventing command line execution
  • Include a bat file (Windows) and shell script (Linux) to launch the application.
  • Implement a way to load a model and diagram that is split into multiple JavaScript files.

Demonstration:

I’ll have a great screen cast coming up this week! Check back.

Retrospective:

Est. Hours vs. Act. HoursEverything went well this week. Nothing much to reflect upon.

 

 


Sprint #9 Planning

This plan is a couple of days late.

Release Plan Revisions

My latest release plan provisioned 2 final 2-week sprints, sprints #9 and #10. Since then, I have been given the requirements for the “final deliverables” for my graduate project. I will need three weeks to produce these deliverables, get feedback, and address said feedback. Thus, sprint #9 will be a one week sprint devoted to cleaning up the technical debt from the last sprint and putting the finishing touches on the prototype.

Sprint #9 Plan

Sprint #9 will consist of two user stories totaling 6 story points. This breaks down to 5 tasks and an estimated 5.92 hours of effort.

User Stories:

  • #30 – Users should be able to run the application from the command line.
  • #31 – Users should be able to split the model and diagram into multiple files

Tasks:

  • Modify the Ant build file to create an “uberjar” of all the libraries
  • Modify the project & Ant build file to put each library’s license into the distribution
  • Solve the classloader problem preventing command line execution
  • Include a bat file (Windows) and shell script (Linux) to launch the application.
  • Implement a way to load a model and diagram that is split into multiple JavaScript files.

 


Sprint #8 Demo and Retrospective

Burndown Chart:

Sprint #8 Burndown Chart

The burndown chart for sprint #8 is an even more pronounced stair-step than the one for sprint #6. I was unable to do any work for the first week of this two-week sprint for a variety of reasons. This means I went 3 weeks without making any progress on the project. Having lost all momentum, it has been very difficult to get moving again. I was only really able to do any coding on the weekends. Luckily, I was able to cram two weeks worth of work into two days.

Completed User Stories:

  1. #20 – The tool should create an initial diagram from a model.
  2. #21 – The tool should save diagrams to a JavaScript file.
  3. #24 -The GUI should have a toolbar and menubar allowing the user to open models, create, open, save, and close diagrams.
  4. #27 – The GUI should allow the user to Pan and Zoom within a diagram.

Completed Tasks:

  1. Tool creates a blank diagram file for a model
  2. Tool writes statements in diagram file to draw tables
  3. Tool writes statements in diagram file to draw foreign keys
  4. Tool figures out how to space out the tables in the diagram
  5. Tool figures out how large to make each table in the diagram
  6. Tool figures out how to lay out foreign keys in the diagram
  7. Figure out how to do translation and scaling in Processing and add Pan/Zoom functionality
  8. When mouse moves near edge of viewer, pan in that direction
  9. Add toolbar and menubar to window
  10. Add open model function and connect to toolbar and menubar
  11. Add save diagram function and connect to toolbar and menubar
  12. Refactor diagramming classes to set up for new features

Incomplete Tasks:

  1. Add toolbar buttons for zoom in zoom out.

Technical Debt:

  1. I still haven’t solved the class-loading problem that prevents one from running the app from the command line. It still runs fine from IntelliJ IDEA. I haven’t tried bundling all the libraries into a single jar. Maybe that would solve it? Is there an issue doing this with libraries under the LGPL 3 and Apache License 2.0? I don’t think so, but I’m not 100% sure.
  2. I don’t particularly like the way the “open diagram” functionality works. I need to refactor it.

Demonstration:

A screen shot doesn’t really do it justice, but I don’t have time to do a screen cast today. Sorry.

Sprint #8 Demo

Retrospective:

Sprint #8 Est. Hours vs. Act. Hours

My (poor excuse for) user stories and tasks were much too implementation specific. They described the “how” rather than the “what” and/or “why”. After getting my hands dirty with code, I discovered better ways to do things. For instance, I initially wanted the tool to pan the diagram when the mouse reached the edge of the window. I was able to get this working but it didn’t “feel” right. It was hard to control. I ended up using scrollbars to achieve the same end with better results and simpler code.

One thing I have determined is that there is no such thing as “sustainable pace” on a project that is done in one’s “spare time” on top of a full-time job. There is a “tolerable pace” or maybe a “survivable pace” in the short-term, but I’m not sure if “sustainable” is achievable.


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 #7 Planning

You may have noticed that it has been a week since the end of sprint #6 with no mention of a sprint #7 plan. My life for the last week has been something of a cataclysm, and I have been unable to attend to this project. I was able to revise my release plan last Sunday and planned the stories that would go into sprint #7. I didn’t get any further. Here I am though, better late than never.

Sprint #7 was supposed to be a two-week sprint. I will attempt to catch up – to do what I had planned for two weeks in one week’s time. Wish me luck! This sprint’s theme is diagram creation & storage plus GUI niceties. There are 4 user stories consisting of 13 tasks. These respectively represent 15 story points and just under 12 hours of estimated effort.

User Stories:

  • #20 – The tool should create an initial diagram from a model.
  • #21 – The tool should save diagrams to a JavaScript file.
  • #24 – The GUI should have a toolbar and menubar allowing the user to open models, create, open, save, and close diagrams.
  • #27 – The GUI should allow the user to Pan and Zoom within a diagram.

Tasks:

  • Tool creates a blank diagram file for a model
  • Tool writes statements in diagram file to draw tables
  • Tool writes statements in diagram file to draw foreign keys
  • Tool figures out how to space out the tables in the diagram
  • Tool figures out how large to make each table in the diagram
  • Tool figures out how to lay out foreign keys in the diagram
  • Figure out how to do translation and scaling in Processing and add Pan/Zoom functionality
  • Add toolbar buttons for zoom in zoom out
  • When mouse moves near edge of viewer, pan in that direction
  • Add toolbar and menubar to window
  • Add open model function and connect to toolbar and menubar
  • Add save diagram function and connect to toolbar and menubar
  • Refactor diagramming classes to set up for new features

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

Release #1

The code for release #1 has been tagged in the BitBucket repository. You can download the distribution zip file and the spreadsheets I have used to do my scrum tracking on the downloads page in the BitBucket repository.

Features Implemented in Release #1:

  • Core Java library for creating database models
  • Ability to create models in JavaScript files
  • JavaScript REPL for interactive access to models
  • DDL generation for the SQLite3 database platform

Demonstration:

Retrospective:

Release #1 Retrospective

Looking back over the past release, it seems that around five hours is a good target for sustainable pace for one week sprints. It takes about two more hours to do the sprint planning, demo, and retrospective for each sprint. This means that I am doing two hours of “planning/reporting” work for every five hours of “productive” work. This is not a very efficient use of my time. Moving forward, I want to try using two-week sprints rather than weekly sprints. By moving to two-week sprints, I should be able to do two hours of “planning/reporting” work for every twelve hours of “productive” work. I will be able to accomplish more in the same amount of time.

Release Plan:

There are ten more weeks between now and the due date for my final deliverable on April 22nd. I will organize this time into one more release of 5 two-week sprints. I have not worked out what will be done in each of the 5 sprints yet, but my goal for the Release #2 will be to create a GUI tool for creating database diagrams.


Follow

Get every new post delivered to your Inbox.