Mid-Sprint Reviews

[Open Source David]

I would like some opinions about a meeting we have integrated into out
scrum methodology - the mid-sprint review.

Our engineering team is broken into 3 sprint teams each working on a
separate sprint backlog (think of it as 3 separate products). Our
sprint length is 3 weeks which gives us a convenient overlap between
teams - no 2 teams end/start a sprint on the same week as another
team.

Each team takes 1 hour each of their non-start/end weeks and has a
mini-review. This was started by one of the UI engineers as a way to
give/receive instant feedback with the team and the stakeholders
during the sprint. And now we are trying to incorporate a "risk
assessment" into this meeting - one of the stakeholders wants to see
the status of each story to better understand which ones are at risk
of not being completed at the end of the sprint.

What is this group's take on this meeting?

[Michael James]

I've seen value from mid-Sprint checkups internal to the team. If it's for outside stakeholders, maybe shortening the Sprint would be a better idea? My own preference is to keep things simple and avoid muddying the waters.

A second issue: As a team member, I probably wouldn't do as good work being accountable to outside stakeholder(s) *and* my Product Owner. The way you described the situation made it sound a bit like that could be happening.

--mj

> --
> 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.
>

[DJoust]

I defintely see value, not only in mid sprint reviews, but constant
reviews where relevant.

There are sometimes points when a few stories may have collated for
business verify. As much as we try to avoid this outside pressures on
the PO sometimes create this problem. In this situation we find it
useful to get together and go over those stories together in a mini
demo, get any issues or misconceptions sorted out immediately after
and push those stories through to done. In other situations internal
review can simply be grabbing the PO after the scrum to show work in
progress to make sure we're on track mid story.

As for feedback from outside stakeholders, we don't do this but
something I would like to introduce. Rather than waiting till the end
of the sprint, if stories are completed or part completed but the
foundations are there, I can definitely see value in showing the
client sooner rather than later. If it's a major piece of
functionality for instance, getting feedback mid iteration or even mid
story will help guide the decisions you make from there on. 'Fail
fast' after all, why wait 2-3 weeks to find out you're going in the
wrong direction.

This doesn't mean encouraging or introducing change to the commited
work for a sprint but could provide clarification on the spot. If
there are major changes to the story then it's something you can
schedule into the next sprint and be prepared for. If you're going
disastrously wrong you could even consider an abnormal termination.

Often we don't have the luxury of a client being able to review
completed work for a sprint on the day it finishes, so sometimes
feedback is given during the following sprint which makes it too late
to put the extra work in. This is especially problematic if this is
the final sprint and something that often plagues us when clients
aren't available!

I'd be interested to hear other peoples views on the above.