What goes on during a Sprint – a Scrum Infographic

What goes on during a Sprint in Scrum? Everything!

Where it starts

Scrum starts off with a big list of requirements (User Stories in a Product Backlog) that are ranked according to the order in which the Product Owner wants them delivered. The Product Owner might create that


Definition of Done

With each User Story comes its acceptance criteria (a Definition of Done). This is a list of things that the Product Owner wants to see when the User Story is complete. Without a solid Definition of Done the Team cannot truly appreciate the needs of the Product Owner and won’t be able to plan their tasks accordingly. A poor Definition of Done leads to:

  • More rework by the Team
  • Wasted effort creating things that the Product Owner doesn’t need or doesn’t value

Estimating and comitment to work

The Team spends 10% of its time doing planning up-front to work out how they’ll tackle the User Stories and then commits to delivering a certain number of them based on the estimate of complexity and the Team’s inherent capability. Once this is done, they go to work!


Working in parallel, not serial

There’s no up-front analysis or design as it’s done simultaneously with the development. It means the usual stakeholder workshops, visual design and prototyping all occur with close collaboration with the Team members at the same time coding and testing is being done.

What if there’s just not enough time?

Designers often suggest that there’s just not enough time to do design in a single sprint. This is true. There’s not enough time to design everything. Instead, a designer only designs the elements that correspond to the User Stories that they commited to delivering for that Sprint. If something is left incomplete at the end of the Sprint, then it goes back into the Product Backlog. This means a designer on the Team needs to be very focussed and communicate any complexity in designing for User Stories to the rest of the Team during Sprint planning so everyone has an understanding of what’s involved. If the User Story is too big to design in a single Sprint, then the Team should simply break it down into smaller pieces so that the User Story can be completed in its entirety by the end of the Sprint.


The Demo

Once everything is done, the Team show off their creations to the Product Owner. If they wanted specific SEO requirements or that it meets usability and accessibility needs, then that’s what the Team demonstrate. One thing I love about this session as a Scrum Coach is that the Product Owner can’t request new features during this meeting. They can only ask questions for clarification.
Because the demo is performed against the Definition of Done, often as a walk-thru to demonstrate the features requested, this session is sometimes equated to acceptance testing.

Learning why something couldn’t be finished

If a User Story is left incomplete (not ‘Done’) by the end of the Sprint, the Team tries to understand why during the Retrospective. If the complexity of a User Story was not truly understood during Sprint Planning, then the Team needs to understand why it made that mistake, and learn from it, so that it doesn’t make that mistake next time.


With lessons learned, and the Team’s items accepted by the Product Owner, the Team is now ready for deployment and to get started with their next Sprint.


I love Scrum. It’s a simple and powerful methodology that when used in its totality turns close collaboration into rapid deployment of solutions. If you want to try it for yourself the best first step is to get a Scrum Coach (something I love doing).

Leave a Reply

Related Posts:

“Netiquette” for online meetings for remote and distributed teams

As with face-2-face meetings, online meetings also have an etiquette (“Netiquette”) to make them effective. One of the 12 principles of the agile manifesto suggests face-to-face is the best option but in today’s world of social distancing and WFH, it is no longer an option.

Here are the guidelines we have found useful for having for online meetings with distributed


22 Stances of a Scrum Master

The Scrum Master doesn’t remove impediments from the team. Their job encompasses 22 wider stances for supporting the team to self-organise to remove impediments themselves, coaching the Product Owner and coaching the wider organisation.


Does agility go out the window when we work remotely?

Many organisations are making guidance on what tools to use for remote teams in response to COVID-19. The situation isn’t a tools problem. This is a people problem – how can people, who are social creatures, successfully work remotely without physical interaction?


Copyright © Zen Ex Machina® and ™ (2019) All rights reserved. ABN 93 153 194 220

search previous next tag category expand menu location phone mail time cart zoom edit close