In some cases, specially at the beginning of a new product, we have a sprint entirely with architectural user stories with no business value but necesary to the product to be sucessful. We usually do task as:

  • Creating skeleton proyect
  • Set up environment
  • Set up continous integration
  • Install common libraries
  • Organizing project architecture

and so on, but setting metings with stakeholders, with see no value of any of this, they feel is a loose of time.


The sprint review ceremony should be carried out or just make an internal sprint review with internal stakeholders?

3 Answers 3



Scrum requires that the event be held at the end of each iteration, even at the beginning of a project. While you might consider shortening it, or shifting the focus slightly towards process rather than deliverables, the event should still be held.

Events Build Cadence

Formally, the Sprint Review is a required event in Scrum. While it's certainly reasonable to keep it short if you have little to demonstrate, it's important to set the tone for reliable cadence early on. This cadence creates:

  1. Predictability. Stakeholders can rely on having an inspection point available every iteration.
  2. Transparency. Stakeholders can be confident that they will have clear visibility into the project at every inspection point, not just when there's good news to share.

So even if you have nothing to show for your efforts (and you do, so keep reading) it's worth holding the event.

Additional Value

Even when you don't have something to demonstrate, a short Sprint Review is useful to invite collaboration with stakeholders. The Scrum Guide provides some clear examples of what a Sprint Review should contain aside from demonstrating deliverables:

  • The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
  • The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
  • Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
  • Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

So, in addition to establishing a cadence, and instilling a sense of confidence in the stakeholders through predictability and transparency, the Sprint Review invites structured collaboration with the Scrum Team!

Things You Can Demo

Granted, you may not be able to demo a product increment. But if you think about it, you can still demo value to the project, especially if you've adopted a test-first agile mindset!

For example, setting up a developer environment or a continuous integration server is demonstrable. Do your developers use an IDE? Grab a projector and demo the heck out of the Intellisense features (or whatever) that will presumably add value to the project through developer efficiency. Keep it short, but explain why it matters!

Did you get continuous integration up and running? I'll bet the team members that did it tested it somehow. Even if they're not pumping product increments through it yet, they must have done something to ensure it's working as expected. Make a visual demo out of that, and explain how this team-facing feature will help deliver the product the stakeholders ultimately care about.

Confessions from the Real World

I'll admit to having cancelled a Sprint Review from time to time, especially at the beginning or end of a project. However, I've always seen doing this as a failure of imagination, or the result of an overly specification-driven (rather than test-driven) approach to the project and its product development methodology.

If you truly can't demonstrate anything, and have nothing that the stakeholders might want to collaborate on, then you certainly don't want to waste everyone's time. In such circumstances, limiting the Sprint Review to just the Scrum Team (including the Product Owner) might make sense. Just be sure to set reasonable expectations about when Sprint Reviews will begin in earnest, and make sure to communicate whatever value your Sprint has delivered to the Product Owner and the stakeholders.

At the front end of a project, even when I haven't held a formal Sprint Review, I've usually still held an informal event to discuss the project's scope, methodology, or approach. This has typically been well-received.

Towards the tail end, there's usually more to show product-wise. However, sometimes stakeholders are less interested in the small, incremental changes at that stage of the project. In those cases, I've sometimes substituted shorter stakeholder meetings for the formal Sprint Review. There, we often talk about schedules, shipping dates, or project close-out topics.

I don't claim that it's a best practice, and certainly don't claim that it's Scrum. However, it's certainly an option if strict framework adherence isn't desired, or when process immaturity or stakeholder apathy make starting (or maintaining) the cadence is impractical.

My real-world experience is that shortening the event, or shifting the focus slightly towards process, can be beneficial in some circumstances. Skipping the event entirely has almost always been a project smell for me, though. I don't recommend it, but your mileage may vary.


Yes! My recommendation would actually be to have a really small goal that is easy to see, but doesn't add much work (or maybe value). It's more of a talking piece than anything. That first review is a great time to set the stage for the project and get people introduced. You don't have to fill the time box, but it's a great no-stress way to start things off on the right foot.

  • +1 for mentioning that even the first Sprint ought to have a Sprint Goal, and that the completed Sprint Goal can usually be presented in some way.
    – Todd A. Jacobs
    Commented Aug 30, 2018 at 2:10

architectural user stories with no business value

I encourage teams to create a very simple 'hello world' style first user story that offers limited but non-zero business value. Then do all the technical setup tasks under that user story.

The benefit of this approach is that it gets the team in to the mindset of always focusing on the delivery of business value and makes it clear that technical tasks are just a means to an end.

As an example, a Business Intelligence team I worked with created a first story:

As a Marketing Manager I want to see the date of the registration report so that I know when it was produced

Then the team did all the setup tasks and produces a very simple online report that included the current date and nothing else. This first story took the whole of a two-week sprint because of all the setup work it included.

  • This. So much this. Use the first iteration to lay out an architectural skeleton.
    – RubberDuck
    Commented Aug 31, 2018 at 0:42
  • 1
    This is what I was going for, but your example makes your answer better than mine. +1
    – Daniel
    Commented Aug 31, 2018 at 18:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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