Simply put, “DONE” is the full list of stuff the team needs to complete to put the story (set of tasks or full work effort) behind them. If there is work still remaining then it isn’t done because this work will either become technical/business debt, or will delay the next work while it is being completed. This is why done can’t be measured by deployed.Anything you would add?This is also why teams I work with are allowed to use the word “complete” somewhat freely, but they use the word “DONE” with respect and reservation.
For every team, this list is unique… and every team should manage/evolve it as they mature. It is a critical part of agile success.
Oh yeah… and it should be filtered through the lens of business value (not tech complete), but this isn’t an issue if your team is cross-functional.
Random comments on interesting posts within the agile software development community...
Wednesday, July 29, 2009
DONE vs. Complete...
From time to time this topic comes up. Today it was raised in my RSS feed by Boggin of the EscApologist blog. He posits "When is a task Done"? He's on the right track, but I was worried his list was too prescriptive. I see DONE criteria as a specific area of coaching and focus for all agile teams, and I think it is more important for people to understand the reasoning behind DONE than have a solution handed to them. This will allow them to find the right answer for themselves. So, here is the nugget I left for him:
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment