devXero's blog

a blog about agile, development, and automation

Should a sprint review be only positive???

Posted by Mike Longin on August 6, 2008

This is a question that comes up from time to time on my team.  Should a sprint review only be about the positive.  And if so what do we do about the negative.

I have 2 examples that illustrate my question.

1.  Your team sets out to accomplish 40 points but only accomplishes 36.  Do you spend any part of the sprint review dwelling on those 4 missing points.  If so how do you go about discussing them.  Or do you wait to the retrospective to discuss them.

2.  Your team has accomplished all of the objectives and stories for a sprint, yet is aware that there is more work left to be done.  The product owner for whatever reasons disagrees over the teams assessment and feels it is time to move on.  Is the sprint review the time to bring up this issue since it is one of the few times that the powers that be are all located in the same room.

These are two questions that time and again we are faced with and have yet to find the answers.


3 Responses to “Should a sprint review be only positive???”

  1. On point #1 – it depends on the dynamics of the sprint review and retrospective. Is the whole team in both? And is the PO/customer part of the team (in both)? If yes… then this is a topic for the retrospective. If no, the customer/PO deserve to hear about this since the “budget” and prioritization are the PO/customer’s. I would then lean towards mentioning it in the review to show transparency, inviting the PO/customer to the retrospective, and finding the underlying causes at the retrospective. If they don’t attend the retro, then the team provides the discussion’s outcome to the PO/customer later. This should not lead to interrogations or repeated discussions each sprint, but it should at least be discussed to find a way to improve the estimation and commitment cycle.

    #2 – same approach as prior. I am confused how there could be work to be done when the stories are marked as DONE. Sounds like there is a gap in the done checklist. Either there is goldplating and the PO is correctly bounding the team, or the team is not doing certain tasks in line. For example, it’s not done without a code review (if you are not pairing). Then, it shouldn’t be shown at the sprint review if it’s not done. Thus, the team needs to make a decision: code reviews are important, don’t show it at sprint review if the code review and pursuing changes aren’t complete. Or, code reviews are not important, demo and move on. My advice in this limited example would be to not demo, don’t take credit, lower velocity in future sprints to leave room for these necessary tasks in your done checklist.

    To your larger question- sprint reviews are about accountability (and therefore trust). If bad things happen, then they might not be positive. The whole point is to bring your customer closer to the process and not delay the amount of time before they uncover the truth on their own. In my personal experiences, the most negative reviews/retrospectives lead to some of the best improvements and changes in the team. They just have to be handled appropriately and coached properly.

    Feel free to email me if you have more questions… I might be able to help.

  2. gatorxero said

    Just wanted to clarify point 2. In my company our QA and developers all have experience with the products we are building. To this end they may feel that certain features are necessary for full functionality of the system to be achieved. At the review from time to time, the members of the team will speak of concerns to help prioritize the backlog. This can from time to time bring the feeling of the review down. Is this the proper time to have this kind of conversation?

  3. If the discussion is about whether something is completed, yes. If the discussion is about new scope that wasn’t originally part of the story, then maybe it should be covered in planning. The relationship with the Product Owner/customer is the key to figuring this out since it is more important to have a successful outcome.

    Down is an emotional feeling. A good facilitator/scrum master will help the team focus on the facts and the goal. Feelings are important, but the team must do what is best for the team and customer. Sometimes this means facing the realities that it could have been better.

    I will say that team dynamics play such a role in your questions that I worry about providing armchair medicine.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: