Sprint review in multiple teams developing one product?

My suggestions are:

- Product Owner and Scrum Master are probably the only two people common across the multiple teams. Depending on the project complexity and variables, they can probably decide what is best Sprint Review mechanism.

- In general, my view is to have separate Sprint Review discussions with multiple teams (they would have had individual Sprint Goals and 'Done' items during the sprint anyway, so the Sprint Review could be specific to those), and wherever the Scrum Master feels more than one group are required, he could bring in the relevant teams for those points alone.

The idea of Scrum is to have an inspection of the Increment in order to decide to ship it or not, and to learn about changes and other feedback to process into the Product Backlog. The decision on ship or not requires an integrated Increment, because that's the only way to have transparency. What would happen if you take this as the starting point, and then consult with the teams on how to organize the Sprint Review?
Sprint Retrospective can be done with the individual teams anyhow.
I always teach that a Product Owner should know about done/not done before the Sprint Review.

It is not the number of Developers that make the Sprint Review big, but the number of attending Stakeholders.
Please note the important note from Gunther: "a Product Owner should know about done/not done before the Sprint Review". This meeting is not for the PO(s), but for the Stakeholders.
I have a customer with many many Stakeholders attending. They do a circuit, a station for each new feature. There, a smaller group of stakeholders gets a quick intro and then they use and test the new feature. The station is run by a Development Team or part of it. Hope, this might give you some ideas.
BTW: It is very important that you minimize the number of presented PPT-Slides to ZERO. The stakeholders get bored otherwise. They must use the Increment, must be able to install it and they must bring their laptop for this.

Interesting points, Daniel and Gunther.. In our project, we hardly have any involvement of 'stakeholders' directly, it is usually the Product Owner who is the end-to-end owner and UAT tester. It will probably be worthwhile inviting few other stakeholders along for the Sprint Review to get an overall feeler from wider audien

Regarding integration of components as part of the demo in Sprint Review, I agree it will make sense for all dev teams to be present.. However, there will be around 25 dev folks, so bound to be a lot of views/opinions floating around. As long as we have all on the same page (maybe a quick informal discussion amongst dev team before the actual Review), it should help I think..

"so bound to be a lot of views/opinions floating around"
Sounds like a great collaborative discussion regarding the future of the
product. Just what we hope for in a Sprint Review.

On Wed, Nov 14, 2012 at 1:19 PM, <ScrumForum@scrum.org> wrote:

>

+1 to more stakeholder involvement -- The PO and/or SM should identify key stakeholders and encourage them to come. As it turns out, while the PO is the main customer rep, they are human, and therefore they are not perfect. :-) I think I read about a team who never invited stakeholders(they claim they were doing all the Scrummy things except this one particular issue). Once their stakeholders saw the first demo of the product(several months later), it was so far off from what they wanted that they worked to have the project cancelled. Definitely get them involved soon!

Also +1 to encouraging a collaboration in the Sprint Review. I have noticed one small anti-pattern with having such a wide audience -- some times the developers try to turn it into a "gripe session" or some session where they act like they know more about the stakeholders' business than the stakeholders do. This occurs, in my view, because they are not given other outlets to communicate with these stakeholders -- that's a real need(that needs to be worked on) -- but it's not the main purpose of the Sprint Review. The main purpose of the Sprint Review is to inspect and adapt the Increment and the Product Backlog going forward. Try to find other collaborations outside of the Sprint review for the off topic stuff.

My advice is to work to educate your team on what comments are appropriate vs. inappropriate for a Sprint Review, and to also remind the dev team that the stakeholders are their customers. Shouldn't you be careful how you talk to your customers? :-)

(Just saw something from Daniel's post that I want to support)

Please note the important note from Gunther: "a Product Owner should know about done/not done before the Sprint Review". This meeting is not for the PO(s), but for the Stakeholders.

SUPER BIG +1 (Though I think this is a common thing that happens for teams/orgs relatively new to moving to Scrum)

I wrote an article on that point: "Worst Practice - The Sprint Review as a Signoff Meeting"
http://www.scrumcrazy.com/Worst+Practice+-+The+Sprint+Review+as+a+Signo…

> I think this is a common thing that happens for teams/orgs relatively new to moving to Scrum

New teams can need fairly heavyweight Sprint Reviews. This is because their Definition of Done might not yet include some of the things needed for approval, and which therefore get deferred to the end of the sprint. Improving the Definition of Done is one of the goals of the Sprint Retrospective, and it can have the effect of making Sprint Reviews less onerous over time.

> New teams can need fairly heavyweight Sprint Reviews. This is because
their Definition of Done might not yet include some of the things needed
for approval, and which therefore get deferred to the end of the sprint.

Can you describe what you mean here a little more?

On Thu, Nov 29, 2012 at 10:53 AM, <ScrumForum@scrum.org> wrote:

>

> Can you describe what you mean here a little more?

The Sprint Primer has a good summary of this, and sets the goal of making a DoD as close as possible to "potentially shippable". There are immersive approaches to agile transitioning, such as the Shock Therapy method, where a DoD is relatively complete to begin with. However many clients only have an appetite for a gradual adoption of agile practices. For them a DoD may be initially quite limited in scope, and the debt incurred may not show until the Sprint Review. As such it may not get paid off until following sprints. Worse, it may not get paid off at all, so that quality cannot be said to be invariant. Something like WaterScrumFall may be their starting point.

In my experience these teams will usually have a nominal DoD that reflects their current understanding of their capabilities, and it might extend no further than application coding. In such cases introducing unit tests can be a good way to acclimatise a team to the notion of "done-ness". But what they will most likely lack are practices such as TDD (tests written first), comprehensive coverage of unit tests or a means of gauging metrics, BDD coverage, peer review or pair programming, team ownership, or effective and timely communication between team members and the Product Owner.

This means that the first a PO gets to see of the work may indeed be at a Sprint Review demo. If the PO is unhappy, then that is when the feedback will be obtained. That's what I mean by the review being "fairly heavyweight". Feedback should, of course, have been elicited during the sprint, captured by tests, and subjected to quality assurance by peer review and/or demonstration. By challenging this during retrospectives, a better DoD can be encouraged that is fit for purpose. A good DoD, when properly applied, can substantially de-risk a Sprint Review and make it a less onerous event for all concerned.

Ian,

This means that the first a PO gets to see of the work may indeed be at a Sprint Review demo. If the PO is unhappy, then that is when the feedback will be obtained.

Help me see it. Help me see why the PO cannot accept the work before the Sprint Review?

I can see it happening only in the most extreme and rare of cases... and I have never seen it myself in the teams I've worked with -- maybe because I coach them that stories need to be fairly small, and I coach the PO early on that work should be accepted/rejected as soon as the Dev Team think's its finished.

> Help me see it. Help me see why the PO cannot accept the work before the Sprint Review?

The PO can, and should, accept the work before the Sprint Review. That's my point. A good DoD will encourage this practice by getting work closer to a complete and potentially deployable state. By exposing the gap between the criteria for acceptance and the DoD, a better DoD can be elicited and the Sprint Review substantially de-risked.

What I'm also pointing out is that new teams (unless they are doing something like Shock Therapy) typically won't be doing that yet, and they need to be helped along. Until then the Sprint Review Demo will be the Last Chance Saloon. New teams hang out there too much. All I will say in its favour is that it is better than no saloon at all.

All I will say in its favour is that it is better than no saloon at all.

I think we may be close to agreement there, and because it's a last resort that will happen only in very extreme cases, I don't ever condone it, certainly not publicly.

I'm not suggesting that you do condone it, either, only that I don't.

I do have some issues with approaches presented here - because in my environment they are not working somehow, and I still strive to identify why.

We have five Scrum Teams, all are working on one product backlog in a four-week Sprints (think: longest allowable timeboxes). We are working on one product, although there is some specialisation present (each team has its own "business domain"). Our product is deployed, stable, DoD is established and currently our Sprints focus on continuously improving a long-ago-mature solution according to business needs. So no possibility of "stakeholders seeing and cancelling the project" - they are actively using it.

1) Potential problem #1: PO is the "main customer rep" - and as Charles said, he is only human. As a person who actively works on the Product Backlog, he won't give us much feedback. This is because he knows the scope of the task very well, and the task was realised according to his description of the PBI + grooming with the teams. So not much feedback to add here. We will try to identify interested stakeholders and ask them to join the review, although only remotely (offices are in different countries). But, when we tried this earlier, the stakeholders were not interested in the review at all and treated it as a boring duty and not an opportunity to collaborate.
2) Problem #2: Teams do not want to have a review together, they are pushing to have separate reviews for each team with PO (and in the future with directly involved stakeholders). On one hand, this gives each team a possibility to collaborate with PO / stakeholders, on the other hand, leaves out other teams, whose work may or may not intersect with current increment. Moreover it will be impossible for PO to do a four hour review with each Team, as the timebox suggested by the guide.
3) Problem #3: What we're doing currently is in fact a demo for PO, not a review, and people strongly want it to stay that way. And the main argument is that „90% of the people are bored and not interested in what other teams do”, moreover, often people are completely not interested in the „demo” of their own increment and treat it as another useless meeting spent when they could be coding. There is absolutely no collaboration, rarely any question arises. A gripe session? That would be REFRESHING! :)

At this point the „resistance” is so strong that I wonder whether we should treat all the Teams involved as one big Scrum Team, or go for separate Teams (and possibly separate product backlogs, although it happens that two or three teams' work is intertwinned each sprint). What is your opinion on this? Should the term „Scrum Team” in „big events” like planning or review mean all teams involved, or should we treat the term „Team” literally?

regards,
StarLight

"Problem #2: Teams do not want to have a review together, they are pushing
to have separate reviews for each team with PO"
Assuming the concerns and risks foreseen are known to the team, the team
should experiment with the setup they feel is most appropriate. It is
their process after all. I would work with them to come up with what they
anticipate happening and then compare that with what actually happens over
time (without making them feel their setup for failure). Help the team
make decisions based on this new reality, not the fear you have.

"Problem #3"
Tell me again why the PO continues to request new work be done? Have you
maximized the return on investment? Sounds to me like there might be
better products and features awaiting.

Personally, it sounds like self-organization is missing in your
organization and whoever is pulling the strings has wrung dry that person's
or persons' set of ideas. Maybe it's time to allow the wisdom of the
crowds take you to the next level. Scary as it may be, you seem to have
the mechanics of Scrum down pretty well.


On Thu, Dec 20, 2012 at 7:58 AM, <ScrumForum@scrum.org> wrote:

>

Posted By Ryan Cromwell on 20 Dec 2012 09:02 AM
"Problem #2: Teams do not want to have a review together, they are pushing to have separate reviews for each team with PO"
Assuming the concerns and risks foreseen are known to the team, the team should experiment with the setup they feel is most appropriate. It is their process after all. I would work with them to come up with what they anticipate happening and then compare that with what actually happens over time (without making them feel their setup for failure). Help the team make decisions based on this new reality, not the fear you have.

But what is the Sprint Review for, then? Is it boldly advertised in the guide that its main goal is collaboration and feedback AND reshaping the product backlog accordingly if needed. Moreover I do not feel that its "their" process. What I would like to achieve is a common agreement that this is OUR process, not separate teams' process. And by separating reviews I feel we're making some kind of "business competence silos" and the whole "collaboration and feedback" thingy goes out of the window. Or I am simply wrong and we should act as there are no other teams, and have separate product backlogs and POs - meaning to treat "Scrum Team" term literally.

"Problem #3"
Tell me again why the PO continues to request new work be done? Have you maximized the return on investment? Sounds to me like there might be better products and features awaiting.

Like I said, product is mature but continuously evolves and is heavily used. There are roadmaps, visions and so on, and there is competition on the market. In that context, there is always much to do, and our PO is "siphoning" all the business needs, converting them into PBIs and ordering them like any good PO should. Moreover he even does demos to the real users (and in fact, stakeholders) of the product. This could be an issue (why attend to two "demos"?), but this is a new practice, and is not the root cause of the lack of direct stakeholders involvement.

And this does not reflect on the lack of developers involvement. I'm beginning to doubt if such "perfect" Sprint Reviews even exists. Or maybe they are only possible in startups, where everything starts from scratch and the product is not mature enough and there are heated discussions going on how should we shape the product.

Personally, it sounds like self-organization is missing in your organization and whoever is pulling the strings has wrung dry that person's or persons' set of ideas. Maybe it's time to allow the wisdom of the crowds take you to the next level. Scary as it may be, you seem to have the mechanics of Scrum down pretty well.

Wisdom of the crowds isn't always right. It may be tempting to take away from Scrum, but as Ken Schwaber likes to say: it will be a ScrumBut. And the most scary part of it is - it will be a "ScrumBut works", because our current "Scrumbutty" implementation suits our needs just fine. But in Scrum we should inspect and adapt, right?

greetz,
StarLight

First have separate reviews then one as an entire team


______________
http://www.agiledistributed.com/