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

Planning

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!

Doing

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.

Checking

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.

Acting

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.

Conclusions

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).
M

About the author

Related Posts:

How do I run a Retrospective?

The Retrospective is one of five events in Scrum. It’s purpose is to inspect the whole Scrum Team from the perspective of people, process and tools, and then adapt the way the whole team works (including the Product Owner).

READ MORE

Better together: Agile + Lean UX

How do you make Design Thinking, Lean UX, and Agile work together. Sprint 0? Design Sprints? Upfront design and planning tends to delay the delivery of value, so there must be a better way to use Scrum but also engage in discovery work at the same time without devolving into parallel design work. Integrating design, user research, and experimentation into Sprints is the key.

READ MORE

How do I run a Sprint Review?

The Sprint Review is one of five events in Scrum. It’s purpose is to inspect the Increment of work, get feedback, and then adapt the Product Backlog. And while many people refer to the Sprint Review as the “demo” or “showcase”, this is only one aspect of the Sprint Review.

READ MORE

How do I run a Daily Scrum?

Many people use the Daily Scrum to provide a status report to the Product Owner or Scrum Master, and even to stakeholders, but this event plays a more critical part in ensuring that the team continues to stay focussed on their goal and adapt their work so they improve their chance of achieving it.

READ MORE