Mike Cohn Suggests Unfinished Work in Sprint Review
Mike Cohn, one of the founders of the Scrum Alliance, challenged the agile community about the contents of a sprint review, suggesting that sometimes it is worth to present unfinished product backlog items.
By definition, the Sprint Review Meeting is the first part of the last day of a sprint, on which the team shows to the customers the product of the last iteration (sprint). For this meeting, the rules are:
- Review the work that was completed and the planned work that was not completed.
- Present the completed work to the stakeholders (a.k.a. "the demo").
- Incomplete work cannot be demonstrated.
- Four-hour time limit.
Cohn starts his post by reinforcing the main rule above - during the demonstration, the team is allowed to show the completed work items of the iteration. By doing this, you assure that the customers will only see the amount of work that is really finished, the one that is compliant with the team's done list.
Then, he talks about the risks of giving a team the permission to present unfinished backlog items:
- False progress of the work really completed.
- Customer expectations rises to a higher level, assuming as done (or nearly done) all of the items discussed during the meeting.
But, based on the fact that the main objective of this kind of meeting is to obtain feed-back from the stakeholders, he states that sometimes it is worth to show some unfinished work: "For example, you may have everyone you need to comment on whether the visual design of this next item meets everyone's expectations. So go ahead, show that feature and get feedback on it. "
Cohn's post has had a lot of different answers and feedback. For example, Илья wrote that Cohn is "opening a dangerous box by telling people they're able to show the unDone work...Yes it's hard and you need a certain courage to show what is DONE only".
On the other hand, Adam Myhr states that showing unfinished work during Sprint Review Meeting "seems to me that breaking this rule is done to accomplish something other than the intent of the Sprint Review. In my mind that is an opportunity for proper use of Scrum framework".
There are several discussions on the unfinished work topic. In a thread at Programmers Stack Exchange, GuyR refers to a much less-common approach: "At the sprint review, the Product Owner, in consultation with the sprint team and stakeholders makes the decision on done-ness". In this case, the items are presented whether they are finished or not.