OK, let’s say you’re on a Scrum team that’s planning its next iteration. You pull a story to implement Feature X for the next release of Application Y. You review the specs, maybe have a conversation or two with the product owner to clarify a few details, and discuss implementation details with your team lead. Cool. Now, you design the feature, code it up, build it and tweak it until its working to your satisfaction.

Then you check it into the source control system and move on to the next feature. Done, right? Not necessarily so! Sure, you can stand in front of the users at Sprint Review and watch them salivate as you demonstrate Feature X in action. But, can they walk out of the review and begin using it right away? Most likely not. If not, is it really done?

“Code complete” is just one milestone on the yellow brick road to Emerald City, where users are happily whistling away while using your excellent Feature X in their Application Y. There is so much more to consider. What about unit testing? Integration testing? Acceptance testing? Documentation? Packaging? Deployment?

Getting an application successfully delivered involves much more than working code. Failure to take this into account, and considering “code complete” to mean the same thing as “done”, inevitably causes a development team to fall behind schedule as they scramble to deliver what was already considered done. This is a form of technical debt, a topic I’ll explore in a future post.

For more information on the meaning of “done”, check out this excellent podcast on HanselMinutes.com:

What is Done? – A Conversation with Scrum Co-Creater Ken Schwaber

A bug is a bug is a bug, right? Not so!

Most development shops treat a bug as a task. That seems reasonable - it's a bit of work that needs to be done. Unfortunately, it's not so easy. If a bug is discovered in a feature that is currently under development, and it will be fixed in the current Sprint (iteration), then the bug can and should be treated as a task. It would be considered a new Sprint Backlog Item that must be closed before the feature can be considered "Done". However, if the bug is not fixed before the feature is considered "Done" (yes this really happens), or the bug is discovered after the feature has be deemed "Done", then the bug becomes a bit of work to be scheduled into a future Sprint. In other words, the bug should be treated as a Product Backlog Item.

The rule of thumb is rather easy really. If the bug is going to be fixed in the current iteration, then treat it as a task. If not, then the bug needs to go on the product backlog and be prioritized right along with all the other Product Backlog Items.

Of course, this raises the question: What does "Done" mean exactly? Many dev teams grapple with this deceptively simple question. I'll explore this question in a future post.

While at TechEd 2008 earlier this month I attended a presentation by Colin Bird where, among other things, he presented the next generation of the Conchango Scrum For Team System process template. According to Colin, Conchango will continue to offer a free version of their scrum process template. But, they will also be offering for the first time an "enterprise" version that they will sell for a yet-to-be-determined fee. This enterprise version will contain an exciting new feature: and Electronic Scrum Board. This WPF application simulates the cork board and index cards that many scrum teams use to track the progress of their sprint. Each row represents a Product Backlog Item (also called a User Story) that describes a specific feature to be implemented, while each card represents a Sprint Backlog Item that describes a specific task. The columns on the board represent the various states for a Sprint Backlog Item.

I took this shot while sitting next to David Starr in the presentation, who also took a snap with his camera phone.

When a card is dropped onto a row the board, it is automatically linked to the corresponding Product Backlog Item, and it's State is also updated automatically. This is sooo much more convenient that the current method of updating work items, and the board methaphor makes it much easier to visualize the overall status of the sprint.

I also happened to be part of the same lunchtime discussion of Electronic Scrum Boards with Jeffrey Palermo that David blogged about. I respect Jeffrey's opinion very much, as well as Dave's reaction to Jeffrey's comments. But my take on the topic is slightly different.

As I recall, Jeffrey was not thrilled about the Electronic Scrum Board because a physical cork board works just fine. The cork board is simple and easy to use. It's highly visible to the scrum team and its stakeholders. Why go to the trouble and expense of implementing an inferior solution?

I get it. But I also beg to differ. First, let's assume that an organization has decided to use Team System work item tracking because it offers rich reporting of current and historical data, as well end-to-end traceability resulting from linking work items to changesets to builds to build verification tests. Now, if a scrum is using both work item tracking as well as a cork board, then the same information if being maintained redundantly. This being the case, it's almost certain that the work items will be out of sync with the cork board some if not all of the time.  With two conflicting views of project status, which one is authoritative? Which one do you believe?

Also, the cork board works great if the scrum team is co-located in one open space. Having all team members together in one location is ideal, but the reality is that a growing number of teams are geographically dispersed - sometimes in different parts of the world. For these teams, the cork board offers a poor solution.

Similarly, project stakeholders are often not in the same physical location as the cork board, making it difficult if not impossible for them to benefit from the information the cork board contains.

For these reasons, I believe that the Electronic Scrum board offers a superior solution. It not only shows current status, it also automatically maintains work item history. Analysis of this historical data can calibrate future estimates, enabling better sprint planning. Also, an Electronic Scrum Board offers a far more practical solution for teams that are not co-located.

Finally, I find it curious that scrum teams are in the business of creating automated solutions for others, but some of these same teams are loathe to give up their cork boards for an electronic version. Doesn't that seem just a bit ironic?