Two-week Product Increment can be usable, but not very usefull. So does PO need to attend every Sprint Demo?

Let's say that a feature is mostly related to adding a new function to a backend. We need a few sprints to implement this backend function and only then the feature can really be inspected. I suppose we can just say PO that we need a few sprints to prepare a Demo, instead of conducting minor, formal Demos every Sprint.

  • 2
    You're likely doing something wrong if your Sprint Goal or Product Goal doesn't provide any value that the Product Owner cares about. Why aren't you doing vertical slices?
    – Todd A. Jacobs
    Jul 17 '21 at 14:31
  • We do. But some User Stories require few efforts on the frontend and many efforts on the backend.
    – Daniel
    Jul 17 '21 at 15:51

So does PO need to attend every Sprint Demo?

The Product Owner should be getting visibility of the work being done by the team throughout the sprint.

The intention of the sprint review ceremony in Scrum is not to inform the Product Owner of the work that the team has done, instead it is to inform stakeholders who are not involved with the team day-to-day like the Product Owner is.

Also, the sprint review is not just a demo. To quote from the Scrum Guide:

The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation


If you are using Scrum, the expectation is that the Scrum Team creates "a valuable, useful Increment every Sprint". Prior to the November 2020 Scrum Guide revisions, the term "potentially releasable" was used.

There is no "Sprint Demo" in Scrum. The event is the Sprint Review. A demonstration may be a component of a Sprint Review, but it is more than a demonstration. A demonstration may be one way for the stakeholders to review what has been accomplished in the Sprint, but the Sprint Review should contain elements where the stakeholders discuss changes in the environment and the Product Goal and Product Backlog are adjusted based on the most recent information.

If it takes "a few Sprints" to implement enough for the work to be reviewed by stakeholders and obtain feedback, that's indicative of other problems. However, there's insufficient information to even begin to understand where the problems could be.

  • Why is it a problem? Not every PI can be finished during one Sprint. And PO may not be willing to inspect intermediate results, because of lack of time and because they know that the team is professional one and makes (intermediate) things right. In other words, PO wants to inspect MVP of the User Story when it is ready, not the pre-MVP results.
    – Daniel
    Jul 17 '21 at 16:33
  • 1
    @Daniel In Scrum, each Product Backlog Item is supposed to be complete within a Sprint: "Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event." If the team does not have PBIs that can be Done within one Sprint and is not producing a useful, potentially releasable Increment every Sprint, they are not doing Scrum. There's nothing wrong with that, but in that case, I'd also begin to challenge some of the other rules of Scrum in order to build a process that makes the team more successful in the long-run.
    – Thomas Owens
    Jul 17 '21 at 20:45

In a nutshell, Scrum is explained like so (emphasis mine):

  1. A Product Owner orders the work for a complex problem into a Product Backlog.
  2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
  3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
  4. Repeat

The idea with running sprints is that you use them as a minimum cadence for delivering working software, or at least have something at the end of the sprint useful to inspect. This is the product Increment (or a bunch of increments if, for example, you deliver more throughout the sprint by using practices like Continuous Integration/Deployment/Delivery). You then use the increment(s) to adapt your strategy and decide on what to work next, or what's important next. You also use the opportunity to do a retrospective to see how you can also adapt and improve the way you are working.

The longer you wait to provide something useful, the longer the inspect and adapt loops, and the more problems or risks that can manifest themselves before you can adapt.

I've seen many companies that develop software and deliver value using an old fashioned approach, like sticking things together into milestones every quarter (at best) using mini-waterfalls, with Gantt charts laying out work in horizontal layers, with a final stage for integrating all the work, etc., but they expect their teams to do Scrum at the same time. What happens is that they just make developers work in sprints, with a bunch of meetings that frustrate everyone because they are empty of meaning (since work is still done in the same old way but differently), but the meetings need to be held because Scrum says so. That is not Scrum.

If you want to do Scrum, then try to follow its rules.

If you are doing something else which works for you, and you are not bothered by the risks or problems that can occur during a large development effort with a long feedback loop to match, then that's fine too. Just don't call it Scrum and don't force people to participate in ceremonies that don't fully make sense on their own, without the other pieces fitting together also.

  • 1
    The only nitpick that I have is that Sprints, at least as of the 2020 revision, are more oriented toward inspection and adaptation than delivery. The idea of delivering once per Sprint was never really an intention, and the 2020 guide says that "the Sprint Review should never be considered a gate to releasing value." If anything, the Sprint is a minimum cadence for delivering working software.
    – Thomas Owens
    Jul 17 '21 at 20:47
  • 1
    @ThomasOwens: I agree with your statement. I've reworded my answer to remove that confusion. Thinking about the increment is just like thinking about the daily. The team coordinates and collaborates continuously, but a daily is there to make sure they have at least one sync point. Same with the increment, you should go for as many as it makes sense and at least try for one.
    – Bogdan
    Jul 18 '21 at 10:27

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.