Good agile teams follow the Agile Manifesto which states that you must deliver a working model at frequent intervals. Moreover, the teams should consider the updated model as the basic standard of progress going forward. In this article at Mountain Goat Software, Mike Cohn discusses how the definition of “Done” is different for agile teams.
The Binary Work Definition of Agile Teams
The problem in a software project is that developers fail to fathom its magnitude until they start working on it. If their work completion status is 90% at the end of each week, they have discovered something bigger each week. The “90% syndrome” is quite common in software project teams. Not because the client has added more features to the existing requirements. The developers could not understand the enormity of the scope in the initial project planning stages.
For example, when Microsoft developers were working on Word for Windows in September 1984, their timeline was 12 months. After 9 months, the team guessed it would take another 13 months. They released the actual product after 5 years and 3 months, finally.
Instead of asking “What percentage done are we with this feature?” agile teams analyze “Are we done with this feature?” The work definition for these teams is in binary—‘done’ or ‘not started’.
- The team members of the agile teams do not have to waste productive hours by answering to half-done work.
- This makes the velocity more realistic albeit a bit depressing. On the brighter side, the agile teams will not feel answerable for overpromising on their deliverables.
- It makes the teams work with small product backlogs per iteration. If you take small items, you can complete it within a sprint. In fact, agile teams prefer taking smaller items so that clients will not count them major deliverable delays.
To view the original article in full, visit the following link: https://www.mountaingoatsoftware.com/blog/why-agile-teams-put-so-much-emphasis-on-being-done-each-iteration