Now you’ve come to the end of your Sprint and finished when you said you would. All that’s left to do now, is Review, Reflect and Repeat…
At the end of the Sprint, hold a Sprint Review meeting. Invite the whole team. Invite all the key business stakeholders. Invite senior stakeholders including executives where appropriate. The more interested parties the better!
Review what was delivered in the Sprint. Demo the software. Whether it’s complete, working software prior to a release, or work-in-progress in a long-running multi-Sprint project, demo what has been completed in the Sprint. Let team members demo the areas they have worked on.
The purpose of the Sprint Review is three-fold:
Following the Sprint Review, hold a Sprint Retrospective meeting. Invite the whole team. Invite the Product Owner. But this meeting is not for the wider stakeholders. Typically it might follow on immediately from the Sprint Review.
The purpose of the Sprint Retrospective is to reflect on how things went during the Sprint. It’s a chance for the team to discuss the Sprint and consider how they could improve things.
Together the team should:
This is a continuous learning process.
Traditional project management methods, such as PRINCE2, also encourage continuous learning, through the production of a lessons learnt report on closure of the project.
The trouble with this is people don’t always remember enough by the end of a long project. Or perhaps there is so much to reflect on at the end of a large project, that there are too many things to consider and the result just isn’t actionable. And often on completion of a traditional project, the project team disperses onto other projects or back to where they came from, preventing them from applying their learnings as a team.
In Scrum agile development, like the product development itself, the learning is in small, bite-sized chunks. Little but often. While there is still time for the feedback to have a positive impact on the project.
The team is now armed with valuable information – about the product, about their performance, and about some of the impediments in their environment, e.g:
All that’s left for the team to do now, is repeat the process, with the greater knowledge gained from above.
Realistically it takes 3 or 4 Sprints for the team to get into a rhythm. To apply the improvements and get used to the process. For the Velocity to settle around a norm. And for the team to gel…
That’s all folks!
So that’s it! That’s basically Scrum, and how you can implement it in 10 easy steps.
Of course, in reality, the steps aren’t all that easy. The steps involve humans. And software development. Tricky combination!
Nevertheless, the Scrum process is inherently easy. And depending on your situation – certainly in my experience – Scrum and agile development can help your success rate in many many ways.
How to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat…