Shweta Darbha explains how teams can review their work and improve themselves after the completion of key projects or after they have adopted Scrum. Learn how your own team could benefit by following this practice after your next project.
The end of a project not only gives team members the satisfaction of having met a milestone, but it also an opportunity for them to step back and objectively review the project requirements, plan, team performance, maturity, and knowledge. Having worked on a few releases of two major products after adoption of Scrum as their development methodology, I believe that the Scrum framework not only allows for an objective review at the end of each sprint, but also creates retrospection as a team culture making introspecting as part of the team DNA.
As more and more organizations adopt and adapt an agile methodology, the key to success is not always to get the scrum processes or artifacts right the first time. Rather, the team should learn better “agility” from each iteration and each project completion as it progresses to the project’s next phase or even a new project altogether.
This article explores how teams can review their work and improve themselves after the completion of key projects or after they have adopted Scrum.
Revisit the Product Backlog
The transition from the typical marketing or business requirement document to a product backlog should not be a challenge, since the product backlog itself is nothing but a set of prioritized requirements. However, the discipline and the level of crystal-clear requirements that the Scrum team can meet require product owners to have in-depth understanding of the requirements early on. Unlike waterfall development, where the engineering team goes through long-drawn iterations of design and design reviews with stakeholders, each sprint requires the complete cycle of design-to-quality validation of requirements from the beginning.
The product owners need to split the epic into reasonable stories with well-defined acceptance criteria. Regarding the prioritization within the stories for the sprint, as well as across sprints, the stories should be in tandem with the requirements described in an epic so that the team meets the requirements in iterations and progresses towards the larger project goal.
Sometimes, it takes product owners a few iterations to understand how granular the stories need to be for a team to create a working piece of software within a sprint.
In order for one to define the “done” criteria, you need the product owner to understand the story while having a holistic view of the epic of which the story is a part of. Because of this, the team and product owner should revisit the stories after the project and look for the following:
- Tasks should not seem like stories. It would skew the burn-down chart.
- Did the team tackle a large story that took more than three-fourths of the sprint time to complete? If so, break up the stories in such a way that each consumes less than half of a sprint. By doing so, you enable the team to do rework on the story if it fails validation.
- Did the story require multiple iterations for the team to understand and implement? Product owners should adopt better ways of writing stories that are more self-explanatory. They should create succinct stories that are aligned to the epic rather than crafting elaborate articles.
- Was the product backlog prioritized in each sprint aligned with the epics and the project goal? The prioritization of stories should not be haphazard, as this can lead to poorly planned sprints that eventually lead to rework and more bugs.
Review the Acceptance Criteria
Scrum enables the teams to define acceptance criteria for each story and, if done the right way, the project’s release criteria are bound to fall right into place like the last piece of a jigsaw puzzle. The fact