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 that product owners can define “done” criteria for each story and the Scrum team can voice its opinion by agreeing or disagreeing with the product owners is a huge step forward—not only for the team members but also for the project execution; this creates an unambiguous and universally agreed upon set of end results for each requirement right to the last granular level.

The acceptance criteria for a story enable quality control and quality measurement at the most granular level of code.  A well-defined, debated, and agreed upon version of done criteria reduces ambiguity and allows the scrum team to code and develop with a clear understanding of what is expected with respect to the story itself, the role of the story for the larger epic, and eventually the project goal. Hence, the done criteria need to be defined and understood by the team members who should keep in mind not only the story but also the epic and the project goal. This exercise helps the team to achieve the following:

• The team has granular done criteria with better details on exceptions handling, error expectations, and design considerations.
• The team has aligned done criteria of each story to the project goal.
• The team now considers done criteria as an important part of the sprint-planning and story-pointing processes.
• The team now works closely with product owners in hashing out the story in line with its done criteria.

As the team evaluates the product owner’s activities and areas of ownership— namely the product backlog or the done criteria—it must do the same regarding its own areas of ownership, such as story pointing and velocity.

Re-evaluate the Story Points
One of the biggest challenges for a team that adopts a Scrum methodology is that the methodology requires that the team members should estimate and assign story points to the new stories. This can be a new experience for freshly initiated team members who are used to having the manager estimate the requirements needed to create a project plan and the planned timelines needed to finish the activities.

Although Scrum empowers each team member to estimate each work item during sprint planning with techniques like story-point poker cards or T-shirt sizing, this empowerment comes with a duty to understand the requirements and a burden to estimate the requirements holistically with an eye on the design, solution, and bigger picture. This is easier said than done.

The team is bound either to overestimate or underestimate stories depending on multiple factors, such as how well it understands the story, technology, solution, and design.

After the team completes a project, it can revisit the completed stories to study the story points awarded to different stories. This acts as a good way for the team to learn any trends. Rather than going on a witch hunt, the team should look at similar stories, either component- or design-wise, and figure out if it has over- or underestimated them.

This exercise provides a training ground for younger and less-experienced team members who need to learn what the stories are and how and why they were estimated. It also helps the team to evaluate its technical knowledge and ponder if it needs to enhance its skills for the subsequent projects.

Since cross-sprint team reviews do not happen during the project lifecycle, conducting such a review gives team members a chance share their experiences around a story-pointing exercise and enable the Scrum Masters and Scrum team to fine-tune further the implementation of the methodology.

Recalibrate the Team Velocity
Team burndown charts are excellent tools that allow you to study the team velocity. During a project, the burndown enables the team to plan the next sprint and retrospect on what is working (or not working) in order to maintain or improve the team velocity during the future sprint.

Once the team has completed the project, the team should review the burndown charts of each sprint and understand the team velocity in a holistic way. This means the team should consider all aspects that impact its velocity, such as technical knowledge of the team members, estimating capabilities, complexity of the story, external and internal impediments, and deviations, to name a few.

The better the ScrumMaster understands the team’s velocity, the better he can understand the team’s training requirements, help it develop its skills, and help the team members plan their activities while also engaging with management to project the team’s capabilities.

The team’s velocity reflects how many story points the team can consume in a sprint. While you average this number out, you should consider a few assumptions like the attrition or absence of team members within the purview of a product or project with similar technological requirements or domains. This will allow management to understand and plan the future estimates for their go-to-market projections

As a team becomes more mature in its understanding of Scrum, the team increases its story-pointing capabilities, which leads to an increase of velocity. Eventually, the velocity will reach a predictable level and level off. Reviewing the team velocity over a period of time and across projects will enable the team to estimate better and also take up new challenges that build upon its past experiences.

Evaluate the Cross-functional Collaboration
The Scrum methodology proposes that each Scrum team should have members from each department or unit who are required for to finish a project. In addition to QA and engineering team members, members from other cross-functional teams, such as technical writers and change managers, need to be included in the Scrum team.

At the end of the project, revaluate how the cross-functional teams were able to participate and work together. Learning whether the organizational structure bolstered the collaboration or acted as an impediment, can help management align various departments to the organization’s agile adoption.

This evaluation can help mitigate mid-sprint impediments like cross-unit communication breakdown or misalignment of goal which can jeopardize a project. Understanding what worked and what didn’t can help the managers better align and commit their teams to a Scrum team.

Final Thought
Reviewing and revisiting the key elements of Scrum can enable members of Scrum teams to share and learn from their experience. This, in turn, can help the team to predict, prevent, and mitigate impediments from subsequent projects. The retrospective should always contain clear goals of what the team is trying to achieve. It’s not an assessment or an appraisal of the team or the team members; rather, it’s a learning exercise in which team members can look back on and take an objective view of the project.