This article outlines my experience with using Agile Scrum to develop enterprise level software. The steps listed below are compiled from across the internet. See the end of this article for sources.

Development Team Metrics

Agile metrics are an essential component of the development process and are critical to communicating development estimates as well as improving the speed / performance of your development team. Metrics are the single most important part of your agile development. They will inform your estimates, timelines, team capacity and if there are shortcomings.  By measuring how productive a team is, agile metrics help keep the team performance in check. If there are any loopholes, they expose them at the initial stages. Since the data and its usage are measurable, it’s easier to work on the shortcomings with the help of these metrics. For example, velocity metrics can help you track the team’s output.

Sprint Burndown Report

An agile framework comprises scrum teams. They organize their processes into sprints. Since a sprint is time-bound, it’s important to track task progress frequently. A sprint burndown report is for tracking the completion of different tasks during a sprint. Time and work left to complete are the two main parameters of measurement in this case. The X-axis refers to the time. The Y-axis represents the work left. The unit of measurement is hours or story points. The team forecasts the workload at the beginning of a sprint. The target is to complete the workload by the end of the sprint.

Velocity

Velocity measures the average work a team does during a sprint. The report, in this case, contains several iterations. The accuracy of the forecast depends on the number of iterations. The more iterations, the more precise the forecast. The unit of measurement is hours or story points. Velocity also determines the ability of a team to work through backlogs. As time passes, velocity tends to evolve. To ensure consistent performance, it’s important to track velocity. If the velocity declines, it’s a sign that the team needs to fix something.

Lead Time

Lead time is the period between the moment of making a request for delivering a product and the actual delivery. All the processes to bring a product to completion come under lead time. It also includes developing a business requirement and fixing bugs. Lead time is an important metric. The reason for this is it provides the exact time calculation for every process.

Throughput

Throughput measures average tasks processed in each time unit. You can also call it a measure for story points per iteration. It represents a team’s productivity level. Throughput helps you understand the effect of workflow on business performance. You can get a better overview of the capacity of your team. However, it doesn’t show the starting point of tasks.

Failed Deployments

Failed deployments is a useful quality metric. It helps in assessing the number of overall deployments. Moreover, teams can determine the reliability of the testing and production environment. This metric also determines whether a sprint is ready to enter production.

Code Coverage

Code coverage measures the percentage of code unit tests cover. You can run this metric with every build. It represents the percentage of code coverage in raw form. This metric gives a decent perspective on progress. But it doesn’t cover other kinds of testing. Thus, high code coverage numbers don’t necessarily represent high quality. Teams should work to be at 100% code coverage at all times.

Product Backlog

The product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome. Development Teams will have access to a groomed Product Backlog. The backlog is ultimately owned by a PM, but items in the backlog will require contribution from all effected teams including Development Team, Project / Product members, Business Development, Integration Managers and Account Managers and component-owners.

The product backlog is the single authoritative source for things that a team works on. That means that nothing gets done that isn’t on the product backlog. Conversely, the presence of a product backlog item on a product backlog does not guarantee that it will be delivered. It represents an option the team has for delivering a specific outcome, rather than a commitment.

Product backlog items take a variety of formats, with user stories being the most common. The team using the product backlog determines the format they chose to use and look to the backlog items as reminders of the aspects of a solution they may work on.

User Stories

User Stories should be presented in the format “As a [persona], I [want to], [so that].”

User Stories should contain:

• Definition of “done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
• Outline subtasks or tasks — Decide which specific steps need to be completed and who is responsible for each of them.
• User personas — For whom? If there are multiple end users, consider making multiple stories.
• Ordered Steps — Write a story for each step in a larger process.
• Listen to feedback — Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.
• Effort — Using agile planning, such as Planning Poker, estimate should be included in all stories in collaboration between Development and Product Owners. Since stories should be able to be completed in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.

Backlog Grooming

Backlog grooming, also referred to as backlog refinement or story time, is a recurring event for agile product development teams. The primary purpose of a backlog grooming session is to ensure the next few sprints worth of user stories in the product backlog are prepared for sprint planning. Regular backlog grooming sessions also help ensure the right stories are prioritized and that the product backlog does not become a black hole.

Backlog refinement sessions present an opportunity for product managers and product owners to explain the strategic purposes behind prioritized items in the backlog. These conversations can help improve alignment across the cross-functional team.

There are also several tactical objectives of backlog grooming sessions:

• Break down large user stories into smaller tasks.
• Discuss user stories with the team, answer any related questions to smooth out any ambiguity.
• Ensure upcoming user stories meet the team’s “definition of ready” by adding key contextual information and acceptance criteria.
• Sometimes (but not always) the scrum master or project manager and delivery team will use this session to estimate stories and assign story points.

At the end of a backlog refinement session, you should have a prioritized list of user stories. You want the items at the top of the backlog to contain the highest level of detail. Any larger stories near the top should be broken down into smaller, more manageable tasks. As you work down the list, stories can be larger and further from your team’s “definition of ready.” The work completed during these sessions will ultimately lead to a greater shared understanding and smoother, more efficient sprint planning meetings.

Sprint Planning

Sprint planning is an event in the Scrum framework where the team determines the product backlog items they will work on during that sprint and discusses their initial plan for completing those product backlog items.

Teams may find it helpful to establish a sprint goal and use that as the basis by which they determine which product backlog items they work on during that sprint.

Who is involved in Sprint Planning

Sprint planning typically involves the entire team.

A product owner identifies the candidate product backlog items and their relative priorities, as well as proposes a sprint goal.

The development team members determine how many of the product backlog items they forecast they will be able to complete and determine how they will deliver those product backlog items.

The scum-master will typically facilitate sprint planning in order to ensure that the discussion is effective and that there is agreement to the sprint goal and that the appropriate product backlog items are included in the sprint backlog.

How is Sprint Planning Structured?

Sprint planning is typically split into two parts:

Part 1 – Scope

The team selects which items from a prioritized list of ready product backlog items (usually expressed as user stories) they forecast they will be able to complete during the sprint.

Here’s a sample agenda for the first part of sprint planning:

• What is the goal for this sprint? Use this as a decision filter to determine which product backlog items to include in the sprint.
• What product backlog items are ready and contribute toward the sprint goal?
• Who is available for this sprint? Identify any vacations, holidays, other activities that will impact everyone’s availability during the sprint.
• What is the team’s capacity based on everyone’s availability
• What items will the team include on the sprint backlog based on the sprint goal and the team’s capacity.
• How confident does the team feel that they’ll be able to meet the sprint goal.

Part 2 – Plan

The team discusses in more detail how they will deliver the selected product backlog items. This may (but does not have to) include identifying tasks for the product backlog items, whether there are any dependencies between the items, and signing up for the initial product backlog items that each team member works on.

Sprint Review

Key inputs into the Sprint Review event include the Product Goal, the Increment, the Product Backlog, the Forecast (or Roadmap), the Definition of Done, the Sprint and any market changes.

During the event, the Development Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment or the Marketplace. Based on this information, all attendees at the Sprint Review collaborate on what to do next. The Sprint Review is a working session and the Development Team should avoid limiting it to a presentation or team building event.

Explain what was done and not done

For Transparency, the Development Team may choose to describe which Product Backlog items were originally planned for the Sprint, and which of those Product Backlog items were done – or not – by the end of the Sprint.  This level of Transparency can be uncomfortable for teams, but it provides stakeholders with key insights into the issues which the team is facing and may be an opportunity for the Scrum Team to request assistance with removing impediments.

Demonstrate working software (or the Increment)

For software development Products, the team may choose to provide a live demonstration or a presentation of the done increment in order to give stakeholders and opportunity to react to what was done and to provide feedback.  You do not need to demonstrate every single Product Backlog Item which was delivered as part of the Sprint, but be sure and cover the most valuable Product Backlog Items which were delivered.  Frequently, the Developers facilitate this part of the Sprint Review meeting because they are closest to the work and best able to answer any questions that may arise.

Collect Feedback

This is the part of the Sprint Review that is most frequently skipped for newer teams.  Many teams do not do enough to encourage sprint review attendees to provide feedback.

Review Forecast

The Sprint review might conclude with a discussion of the Product Forecast.  The Forecast is a prediction of what features or functionality might be delivered next, and when.

Retrospective

The team meets at the end of each sprint with all team members to explicitly reflect on the most significant events to have occurred since the previous such meeting, and take decisions aiming at remediation or improvement. All team members should turn on their cameras – it’s always nice to see each others’ faces. The key is to give your teammates a voice and make them an active part of the meeting – because you’re not doing retrospectives for your team, but rather with your team.

Retrospective meets should always start with something interactive like a team poll. For instance, I ask my team something like: “How’s September treating you so far?” I often make it a rating poll, to run a quick pulse check on how the team is feeling.

The important thing is to follow up on the answers your team has given in the poll. I always encourage a short discussion afterwards by saying, “Would anyone like to share how they voted, and why?” Also, I try to involve the less vocal people in the team by calling out on them directly.

Run stop-start-continue in breakout sessions

A stop-start-continue round is a method that helps teams improve thanks to identifying things they should stop doing, start doing, or continue to do the way they were done before in order to reach success.

Ideas you’ve discussed throughout the meeting must be turned into actionable next steps. This is especially important for ‘stop’ and ‘start’ parts.

Promote positivity

Promote positivity during your team retrospective is acknowledging people’s hard work and celebrating all the good things they helped achieve. This can include demos, accomplishments or even new skills.

More Learning and Sources

https://www.atlassian.com/agile/project-management/user-stories

https://www.agilealliance.org/glossary/user-stories/

https://www.agilealliance.org/glossary/heartbeatretro/

https://www.agilealliance.org/glossary/sprint-planning/

https://www.productplan.com/glossary/backlog-grooming/

https://www.plutora.com/blog/agile-metrics

https://blog.sli.do/your-7-step-guide-to-running-an-effective-team-retrospective-session/

https://www.agilealliance.org/glossary/backlog/

https://www.scrum.org/resources/blog/making-most-sprint-review