2

I have a question about the Sprint review (demo) meeting from Scrum, which is held at the end of each sprint in combination with repositories and the git workflow.

I know that unfinished work from the sprint will be placed back on the product backlog. This is very easy with the codebase because the unfinished work is in a separate feature branch.

The question that I have is when the product owner declines a fully created user story which is already merged to the release branch.

For example, when a user management page is created, there can be user stories about "viewing all users" and "create a new user". The "create new user" needs the overview because this is the only way to get there and be able to use it. So in development, the overview user story is developed and merged to the release branch, then the "create new user" user story is developed and also merged back to the release branch.

So when the product owner declines the "create new user" user story:

How can we remove this functionality alone from the release branch?

  • Why is the user story being "declined"? – Thomas Owens Mar 8 '16 at 12:46
  • 2
    The review is not for acceptance or declination of stories. It is to gather feedback on the completed increment. The PO may not "decline" stories at this ceremony. Your Scrum Master needs to provide the PO with some education, and the PO needs to become more engaged throughout the sprint. – Todd A. Jacobs Mar 8 '16 at 16:02
6

TL;DR

Scrum is a collaborative process between the three defined roles (Product Owner, Scrum Master, and Development Team). You are experiencing problems with your Scrum implementation because your Product Owner is not collaborating throughout the process.

The Scrum Team (including the Product Owner) collectively agree to a Sprint Goal for each Sprint, as well as a Definition of Done for stories or Product Backlog Items (PBIs) that will be done within the Sprint.

Work is "done" or "not done" according to these criteria. There is no framework provision for rejecting work that has met the agreed-upon criteria. However, there are opportunities to iteratively improve the product, and to inspect-and-adapt the process.

The Sprint Review

The Sprint Review is the place to demonstrate whatever work was completed during the current Sprint. It is a formal ceremony within the Scrum framework, and has a specific purpose:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

The Sprint Review is not intended to be an increment-acceptance or status-report meeting. It's simply a way to collaborate on what should be done next within the project, and for stakeholders to participate in the iterative design and implementation of the product.

Fixing Your Process

The Product Owner should be involved through the Sprint. He should be constantly available to the developers, part of the daily stand-up, and working closely with the Scrum Master to track burn-down, the Definition of Done, and other metrics that relate to the defined Sprint Goal.

If the work-in-progress will not achieve the defined Sprint Goal, the Product Owner may collaborate with the team to modify scope, or to call an Early Termination and a return to Sprint Planning. During the Sprint Retrospective, the Product Owner and the Development Team should also collaborate to improve the quality of user stories, add acceptance testing into each Sprint as part of the Definition of Done, or make other process changes to reduce the likelihood of failed Sprints in the future.

However, work that is completed in accordance with the defined Sprint Goal and that meets the agreed-upon Definition of Done is complete whether or not it's what the Product Owner or stakeholders originally envisioned.

Unless an increment has not met the Sprint Goal or the Definition of Done, the work may not be rejected. However, the Sprint Review is the place to hammer out how to iteratively move towards what stakeholders really want now that they've seen how what they asked for has been implemented. After that, the Sprint Retrospective is the place to identify process or communications improvements that will help the Scrum Team and the organization collaborate better in the future.

  • Thanks for the clear information about the review and tips how to solve the problem. Your answer plus the one from Barnaby helped me a lot. – Sven van Zoelen Mar 9 '16 at 8:14
4

It would be worth taking a step back and thinking about avoiding the problem in the first place.

The sprint review should not be the first time the Product Owner sees the functionality built during the sprint. They should be exposed to the functionality at the earliest opportunity, this is often when it is still under development. Typically the sprint review is more focused on stakeholders who are unable to spend the amount of time the Product Owner does with the team.

If the Product Owner is watching the stories getting built it is unlikely they will suddenly reject them at the sprint review.

It is also worth noting that one of the goals in creating user stories is to make them independent of each other. If the 'create new user' story is dependent on the 'viewing all users' story then you will always run the risk of this kind of issue happening.

It is a challenge to keep stories discrete, but it is possible. One way of doing this is to use something called a 'feature toggle', where the feature can be switched on and off independently of other features. In the example you give of the 'create new user' story being rejected, a feature toggle could be used to disable this feature until the Product Owner is happy with it.

Finally, if you are using a source control such as Git then there is a lot that can be done to roll back a particular feature commit without throwing away other code. You may want to consider having feature branches for each story that are regularly merged with your release branch. If this kind of issue occurs then you roll back any commits to the release branch related to the story and roll forward any other commits that occurred in the meantime.

This kind of approach to source control is tricky though and it is preferable to avoid the problem in the first place.

  • Thanks for the information and the tip about feature toggles! Your answer plus the answer from CodeGnome made it clear to me that the PO need to collaborate more during the sprints so that it's clear what is developed. – Sven van Zoelen Mar 9 '16 at 8:03
0

It would be most helpful to know why the given feature is being rejected by the Product Owner so late in the process. Barnaby Golden's answer is in the right direction, but I don't think it goes far enough.

The Product Owner is the person who prioritizes the epics, features, and stories in the Product Backlog. Now, there may be technical dependencies between stories and the team must ensure that the Product Owner recognizes this. This happens at the Sprint Planning meeting when items are being pulled out of the Product Backlog and put into the Sprint Backlog.

If the "view all users" story is a high priority, but it has technical dependencies on a lower priority "create user" story, then it makes sense to implement the dependency first so that the desired story can be delivered. The Development Team should work with the Product Owner to ensure that these technical dependencies are understood.

Barnaby Golden's answer also discussed feature toggles, which is something that Martin Fowler recently wrote a great deal about. But I don't think that they should be necessary if your process is collaborative. The Development Team and Product Owner should come to a consensus of the contents of the Sprint Backlog before the start of the Sprint. Then throughout the sprint, the Product Owner should be involved in ensuring that the work that is done is going to meet the needs of the Stakeholders. There should be no reason to need to remove or add the ability to toggle a feature at the end of the sprint. If a toggling a feature is necessary, that's something that should be discovered well before the Sprint Review.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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