SCRUM Resource: Lessons Learned in Managing Object-Oriented Development

SCRUM project management is becoming increasingly important as scalability of SCRUM across multiple projects in large organizations is attempted. On 18 December, I posted a note on how to provide charts and graphs for management of a SCRUM project in less than 10 minutes per day.

For those implementing SCRUM, it is useful to understand the historical experience that has led to development and enhancement of the SCRUM process in recent years. A better informed SCRUM Master will run a better SCRUM.

Today, I was filing away one of the early papers that was useful in thinking about managing object-oriented development projects. SCRUM works for any type of project, but it is particularly adapted to the iterative cycle of object technology projects. The Pittman paper is as relevant today as when it was written in 1993. For those of you in large companies, it even indicates how to estimate projects using Barry Boehm's COCOMO methodology. While this is not necessary for most SCRUM projects, it can be useful in satisfying even the most demanding beaurocracy. It also will force you to think hard about the key forces that drive project success. Check out:

Pittman, Matthew. Lessons Learned in Managing Object-Oriented Development. IEEE Software 10:1:43-53, Jan/Feb 1993.

Boehm, Barry et al. Software Cost Estimation with COCOMO II. Prentice Hall, 2000.

SCRUM: Dealing with Bugs in a Sprint

Update on 17 Sep 2008: Please note that this is a very old posting in the early days of PatientKeeper before we learned how to eliminate the "QA Sprint" or "stabilization Sprint" before going to full production in a hospital system. The stabilization Sprint fully involved cross-functional teams. In 2003, a new CEO asked why the definition of DONE couldn't be at least four large hospitals system live with no outstanding issues at the end of every monthly Sprint. It took us two years of work to achieve this and beginning in 1995, PatientKeeper goes live at the end of every Sprint with no extra time for QA, regression or performance testing. Also the Sprint in this posting was an emergency that painfully taught us that a Sprint longer than one month should never be done. This Sprint represents a failure mode that we have never done again.

The good news about this posting is that it shows how early PatientKeeper implemented the best Scrum tracking system I have ever seen. It stills has significant advantages over any Scrum tool on the market. It has been migrated to Jira as the underlying storage system for all tasks. Bugs are simply another development task in this system.

Recently a question was posted on the object-technology list asking how to handle bugs during a SCRUM sprint. We have refined the art of SCRUM project management at PatientKeeper during the past couple of years to handle multiple simultaneous sprints with thousands of simultaneous tasks, integrating bug tracking with development project tracking. The requirement for the project management system was less than 60 seconds per day per developer to update, and less than 10 minutes per day for the project manager to do complete reporting with charts and graphs.

In order to meet this requirement, the developers could not use any other software program than the bug tracking system they already used. We added only a few data items to include development tasks in with bugs - class (development task or bug), initial estimate, time invested, and percent complete. Our team was already using an the open source bug tracking system GNATS. We enhanced GNATS with these data items and the ability to dump data into an Excel spreadsheet automatically, every day, for the project manager.

The Burndown Chart above was published in: Sutherland, Jeff. Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies. Cutter IT Journal 14:12:5-11, Dec 2001. If you would like a copy, send me email.

The chart represents a rather long Sprint required to deliver Release 6 of the PatientKeeper mobile product for clinical results. Planning for this project started in April (while another release was in progress) and development items were entered into GNATS which included initial estimates. Initial estimates are frozen and cannot be changed after entry. This allows us to assess estimation accuracy at a later date. You can see the backlog building as new project pieces are entered. The Sprint was kicked off in June and there was a rapid increase in backlog as product marketing added new tasks and developers found out their initial estimates were too short or tasks were missing. In the initial part of a Sprint, the challenge is to get the backlog complete and start flying the backlog curve down into the delivery date. In this case delivery had a hard stop at 20 August.

As bugs are found they go into the same system. It is possible to enter estimates for fixing bugs, but we usually track them by count. The data dumped to the project manager allows the data to be look at in multiple ways. It also shows bug inflow and outflow by day so you can see how many bugs are being found and fixed as you move forward.This metric is one of the most critical information for assessing stability of the code, as well as the success of the project. In the development Sprint which ended on 20 August in this chart, the focus is on cumulative days remaining for unfinished tasks which includes testers working with developers to eliminate bugs. On August 20, we moved into a stabilization sprint to assure the system was fully production ready and take it live at a large hospital system. The teams then shifted to focus totally on bug counts remaining day by day, including inflow and outflow.

Testing is going on during the development cycle and tasks should not be completed until high priority bugs are eliminated. If bugs are found after the task is logged complete, it can be reopened, or the bug can be fixed by the developer owner in the midst of working on other tasks. In any case, this effort is reflected in a rising or falling backlog curve. At the end of every day, each developer reviews tasks and bugs being worked on in the same GNATS user interface, and updates the database in less than 60 seconds.

This is the best project management system I have ever seen or experienced. Time required for update and reporting project management statistics has been reduced by at least two orders of magnitude over other approaches I've seen. In addition, the Backlog Curve reflects thousands of individual estimates that are updated daily. This micro-costing of the project effort yields more accurate estimates of project completion than other approaches. Highly recommended!