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.