Is it done…done? The elusive potentially shippable product increment.
You’ve probably heard this conversation before (or even been a participant):
Developer 1: I’m done with the Foo functionality?
Developer 2: Is it tested and documented too?
Developer 1: I said it was done, not done done!
A question that arises often for many Scrum teams is “When is some particular functionality done?” A primary rule of Scrum is that at the end of every iteration, or Sprint, the Team must build a potentially shippable product increment. That is Scrum’s definition of “done”. So, what exactly does a potentially shippable product increment mean?
The first thing a Team needs to understand is that potentially shippable does not necessarily mean shippable. What it means is that if a Product Owner decides that they want to immediately implement the functionality developed during a Sprint, they could. So, what must be accomplished to consider specific functionality able to be implemented immediately? If you ask ten different teams, you will probably get ten different answers. Some may consider designed and coded software potentially shippable. Others may insist on testing and user acceptance. In short, there are numerous ways to define “done”. Check out the diagram below which illustrates the range of what “done” can consist of.
A Team can feasibly decide that “done” means everything from Analysis through Live. The goal of any Team should be to extend the range of “done” as far as possible. Our Team currently defines “done” to mean analyzed, designed, coded, tested, and documented. However, we’re still struggling with what exactly documented means. Some of our Team believes that developer documentation is enough. Others have document their functionality in our project Wiki. I would personally like to see User Documentation. I think that if something is to be potentially shippable, that means that end users have some sort of documentation, even it’s just in help files.
So, the next question is, how well does the functionality have to perform to be considered potentially shippable. I don’t believe that functionality has to be completely cohesive to be shippable. Mike Cohn gives a good example of this: “We can develop the Print Preview functionality and consider it potentially shippable, even if we can’t print yet.” That means that we have developed a piece of complete functionality that does what it is supposed to do and does it well. It lets the user preview what they want to print. As for the actual printing, we may tackle that in the next Sprint. But if you want to do print previews, we’ve got that for you now, it’s “done”. You can implement it today and starting print previewing to your heart’s content.
My best advice to other Scrum Teams is to clearly define what “done” means for your Team. Take some time as a team to think about it seriously, write it down, and post it in your Team room if you need to. Currently, our Team places individual task cards on our Sprint Task Board to make sure we are not just designing or coding our functionality, but also testing and documenting it. I am confident that eventually, we’ll get to the point where everyone on the Team recognizes our definition of “done” and no longer needs those prompts. It will just be part of our project Zen.
Finally, clearly communicate your definition of “done” to your Product Owners, and strive to constantly meet that definition. It’s important that your Product Owners can clearly see what has been “done” in each of your Sprint Reviews. If they view functionality that is truly “done”, they’ll be able to provide better feedback for the Team. And, if they ask for a particular piece of functionality to be implemented tomorrow, you’re Team will be able to confidently deploy that functionality. It’s what a good Product Owner expects, and what your Team should be able to deliver.
So, the next time you ask one of your Team members if they’re done with the Foo functionality, you should be very clear about what they mean when the tell you it’s done…done!
© Copyright 2007, ChrisSpagnuolo.com GeoScrum! by Chris Spagnuolo is licensed under a Creative Commons Attribution 3.0 United States License.
Related posts:
“Check out the diagram below which illustrates the range of what “done” can consist of.”
Is it just me or is this diagram missing?
Thanks in advance,
K9us
[...] is really ever done done until it is in Main. (see common misconceptions of done here and here). You need to do a Reverse Integration merge from the Release Branch into Main to carry the bug [...]
[...] weeks. Remember, tasks should take less than two days, but this was two weeks and not one thing was done. [...]
Add A Comment