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 commitment 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 committed 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
