(Hopefully powerful) questions to ask in a sprint review

[Carlo Kruger]

I've been thinking a great deal about the mostly flaccid sprint
reviews I've seen recently. So I'd like to share my, and ask for your,
contributions to a list of questions we should be asking in a typical
sprint review. My list so far (in no particular order):

Questions to ask in the Sprint Review

Who is the user who benefits from this feature?
What is the value gained from this feature?
Have we incurred any technical debt as part of implementing this feature?
How long did it take for this feature to be developed (cycle time)?
What other systems (up stream or down stream) may be impacted by the
implementation of this feature?
Has this feature been deployed yet?
Has the development of this feature impacted on any other stories (or
their priority) on the backlog?
What technical debt did the team discover in developing this feature?
What impeded the development of this feature?
Was the root cause of the uncovered impediments removed?
Were there any dependencies (particularly cross-team dependencies)
uncovered during the development of this feature?
Did we use this feature development as an opportunity for cross-skilling?
How did the feature development contribute to the sprint goal?
How did the feature developed contribute to the Product Vision?
How can we improve on this feature?
How does this feature compare with similar features in other products?

m: +27 83 292 6632
t: twitter.com/ironicbuddha
w: http://carlokruger.com

[Rafael Sabbagh Armony]

Hi Carlo,

how are you? :)

Who is asking these questions to who?The PO is asking them to the
team? The team is asking to itself?

The Sprint Review should be an informal presentation of all the team
did that sprint to the PO and to any stakeholder that is present, not
an interrogatory. So, what our PO asks is: "team, what do you have to
show me?". That's not flacid, that's Scrum.

In your list, the PO should know the answer for many of the questions
(the two first, for instance) even before these items are chosen for
the sprint backlog. And most of the others issues should be resolved
by the self-organizing team itself, with the help of the ScrumMaster,
and the PO should only worry about the value generated to the client.

Hope I have helped! :)

Best,
--Rafael Sabbagh
http://scrumability.net

Enviado de meu iPhone

Em 09/04/2010, às 05:38, Carlo Kruger <ironic...@gmail.com>
escreveu:

> --
> You received this message because you are subscribed to the Google
> Groups "Scrum Alliance - transforming the world of work." group.
> To post to this group, send email to scruma...@googlegroups.com.
> To unsubscribe from this group, send email to scrumallianc...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en
> .
>

[Carlo Kruger]

Hi Rafael

(great to hear from you)

What I am observing is that most team members are passive during this
time. (Why that is, is a good subject for a retro, but the pattern
seems quite common in the teams I've coached recently.) So what I am
trying to get at with the list of questions is a guide for teams and
stakeholders to be asking themselves (and each other) as part of the
inspect and adapt phase inherent in the review. I don't expect that
each time the questions would be asked of each item (would take too
long for one thing). But for a new team, this might be a good sense of
what they should be thinking about (all the time really but
especially) in a review.

I am also not sure I agree that the dialogue should be structured as
"team show PO". I prefer that the PO and the team should have been
collaborating during the sprint very closely. (Bob Schatz says it
better than I can at :
http://www.scrumalliance.org/articles/124-the-sprint-review-mastering-the-art-of-feedback
)

I agree completely the any of the questions /should/ have been asked
prior to the review, but the review is also a potentially different
group of people who should use this opportunity to think again about
the items just delivered and see how the product could be improved.

C

m: +27 83 292 6632
t: twitter.com/ironicbuddha
w: http://carlokruger.com

[Mark Levison]

Rather than ask questions I would ask them why they're so quiet? I like the PO to run the demo, no better way to understand what is happening with the application. I like the team members who worked on the story to talk about it and reveal the pitfalls.

If that isn't happening I would ask the team why? I wouldn't introduce new questions that might mask the real issue.

Cheers
Mark

		Mark Levison | Agile Pain Relief Consulting | Agile Editor @ InfoQ Blog | Twitter | Office: (613) 862-2538 Recent Entries: Self Inflicted Agile Injuries, Why use an Agile Coach

[Carlo Kruger]

Hi Mark

I agree with you. What intrigues me I guess, is that we have many books on planning (Agile Estimating & Planning, User Stories Applied) and Retrospecting (Collaboration Explained, Agile Retrospectives) which provide guidance and ideas beyond those offered in the basic texts (Scrum Guide & Ken's books).

Reviews are generally given only short discussion with the general drift being as you've described below.

What I am looking to provide is guidance beyond the 'just talk about it' approach. Particularly with a new team, they need some cues as to what to do. They may be quiet because they're not sure what they're supposed to be doing.

C

m: +27 83 292 6632
t: twitter.com/ironicbuddha
w: http://carlokruger.com

[Bob Schatz]

Hi Carlo,

I think these questions are all valuable, however, they should be
asked long before the sprint review.

I think you will find my articles from the SA website in regards to
Sprint Reviews helpful. The links are:

http://www.scrumalliance.org/articles/124-the-sprint-review-mastering-the-art-of-feedback

http://www.scrumalliance.org/articles/48-successful-sprint-reviews

Please contact me if you'd like to discuss further.

Bob Schatz
Agile Infusion
http://www.agileinfusion.com
http://www.linkedin.com/in/bobschatz

[Rafael Sabbagh]

Hi Carlo,

it's just that anything that sounds too prescriptive scares me! :))

But I got your point of view: those are important things that should be clear to everyone involved. Be careful, though, because people tend to transform this kind of thing in formulas to be followed. And that's everything Scrum is not.

Also, I just don't think all those questions belong to the review. Most of them should be asked (to themselves) long before the review.


Best,
   Rafael Sabbagh

Just be careful with that. I believe

[Bachan Anand]

Hi Carlo,
I agree with Mark and I would ask myself and hold the mirror to the team to ask themselves , reason behind the silence with during review meeting.

I don't want to jump into conclusions about your situation, however I have been in situation where the team was silent during Sprint review and it had a lot to do with

• First time most of  the team members have started working directly with PO and the business users. Before most of the business interaction was done by the Business Analyst / User Proxy in the team.
• What we deliver is not of business value and that limits discussion and interest from business side.
• Trust between Team , PO and business users and team waiting for someone to give permission to ask question.

Frinally it all boils down to just as you have already done , keep asking why and it will give you to the answer.I like the depth of your simple and basic questions, going behind the why may solve bigger problems.

Would love to hear how you and your team is making progress.

--Bachan

--
--Bachan Anand
+949 - 892 5482
Conscires  - knowledge shared with others

[Carlo Kruger]

Hi Bachan

Thanks for the input. I think one point which I should add as I think it does matter, is that this is a multi-team sprint review (5 teams) working from a single organisational backlog, where the teams are still mostly in transition to being truly cross-functional.

The large number of people in the room (between 30 and 50) mean that there will likely be a number of 'passengers' and the ScrumMasters are still inexperienced and are not actively facilitating the discussion.

Regards,

Carlo

m: +27 83 292 6632
t: twitter.com/ironicbuddha
w: http://carlokruger.com

[Mark Levison]

Just catching up on some emails. Sorry for the late reply.

On Sat, Apr 10, 2010 at 4:08 AM, Carlo Kruger <ironic...@gmail.com> wrote:

Hi Bachan

Thanks for the input. I think one point which I should add as I think it does matter, is that this is a multi-team sprint review (5 teams) working from a single organisational backlog, where the teams are still mostly in transition to being truly cross-functional.

The large number of people in the room (between 30 and 50) mean that there will likely be a number of 'passengers' and the ScrumMasters are still inexperienced and are not actively facilitating the discussion.

It sounds like the Scrum Masters need some coaching and help in bringing people out of their shells. I wouldn't make the review meeting the focus in that case. I would work on having great, interactive Planning and Retrospective meetings. If you do that I think the Review meetings will follow.

Cheers
Mark

		Mark Levison | Agile Pain Relief Consulting | Agile Editor @ InfoQ Blog | Twitter | Office: (613) 862-2538 Recent Entries: Self Inflicted Agile Injuries, Why use an Agile Coach