2

This is sort of a follow-up to my previous question Should we quit trying to do agile if QA takes 12 weeks?

For the second time in as many sprints, we've set a sprint review that is scheduled to feature just a single issue that essentially amounts to an obscure bug fix or at most an esoteric enhancement to some small portion of our product. The only real stakeholders for this issue are the single developer and the customer who opened the issue.

It seems to me that given these parameters, we are probably better off just not doing a sprint review. Is there a general consensus on what types of stories should be discussed during a sprint review and what should be left out, or should everything be fair game? We haven't been doing retrospectives at all unfortunately, so unless that changes, that reason is kind of out as a reason to go ahead with the review.

Improve this question
2
  • 1
    Not on topic, but aren't you worried that these questions will get back to your team? They are fairly specific. You haven't said bad things about individuals or anything like that, but would they appreciate you using such a public forum? You needn't respond (especially if it makes the possible problem worse), but perhaps you should be concerned?
    – psr
    Sep 1, 2011 at 0:48
  • No, not really concerned, because these are arguments I'm prepared to make with the necessary people internally. The post is a bit of a rant though, so I'm going to edit it.
    – David Hosier
    Sep 1, 2011 at 1:55

2 Answers 2

Reset to default
2

The purpose of a sprint review is to demonstrate all the things your team accomplished during the sprint, to show that you met your team's sprint goals. Per Mountain Goat Software a sprint review meeting should be lightweight, informal, and hands on - that is, don't spend a lot of time preparing for it, be ready to answer stakeholders' questions and address concerns, and show them working software.

In my experience the sprint review is a great opportunity for the team to pat yourselves on the back and brag a little. Writing high quality software is difficult and any release is a time to celebrate. It helps keep a pulse on progress, builds morale, and builds confidence with the stakeholders. For this reason I think anything you can demonstrate is fair game for a sprint review. If you're collecting software metrics (e.g. complexity and size) you might even demonstrate behind-the-scenes things like technical debt reduction during a sprint review but this depends a lot on your stakeholders.

If you are feeling like there is nothing to show and that the sprint review is of little value, I wonder whether the team added meaningful value to the software during the last sprint? What was everyone else on the team doing during this time? Why is there nothing else to show? What were the goals for the sprint and were they met? How do you know the goals were satisfied (show me, don't tell me)? Is the team proud of the work they've accomplished? Answers to these questions will likely point to problems beyond whether or not to do a sprint review.

Improve this answer
1
  • Sorry for the delay in accepting. Your answer is reasonable, and you bring up some great questions. My question came from a place of frustration, because our Agile effort is completely derailed. But it's like talking to a brick wall trying to get any realistic assessment of the situation. We have new PLM on board, and I think these questions you pose in your final paragraph are a good starting point to begin the conversation with her to hopefully get a fresh start. Thanks.
    – David Hosier
    Oct 4, 2011 at 16:19
0

How long of a meeting were you thinking this to be? I could this being a fairly short meeting though it may be worthwhile to get feedback on what other enhancements or changes the customer that initiated the change may want in future releases. This is also the time for the developer to show to the team what was done that may be important for others to see or note down the road. In seeing the feature, the customer may have some new questions or concerns that are worth noting for future work.

Retrospectives are different from reviews as the former is just the team meeting to discuss how things are going. What is working well? What could be improved? These are part of the heart of having that meeting where a team can check its performance and see how it is doing. Why are the retrospectives not happening? Is it a matter of time, priority, maturity, or something else?

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.