When will you be done? This question often crosses the lips of executives, and rightly so. Executives need to know timelines to make informed decisions about prioritization at the company level and achieve the company’s vision. Regardless of whether it’s a traditional waterfall project or an agile product development effort, knowing the work status is vital, and scrum teams must be able to answer it with tactical status reporting.
Scrum teams need to know how they’re progressing toward accomplishing their sprint or release goals. In fact, they’re obsessed with it. Achieving the sprint goal means they’re helping to solve a customer’s problem in the time frame they need it.
The empirical process
What makes agile status reporting different from traditional waterfall status reporting is that its basis is empirical process controls. Scrum teams use their velocity as a data point for future forecasting, turning their historical development speed into realistic forecasts.
With empiricism, teams are continually inspecting and adapting. They welcome change, even late in development (agile principle 2), and understand that working software is the primary measure of progress (agile principle 7), rather than a Gantt chart or project plan.
While they plan to meet customer needs early and often (agile principles 1 and 3), they value adapting to change over following a plan (agile value 4). Status can change every day, even throughout the day, depending on what the team learns. Scrum teams inspect and adapt by using transparent information, such as story point and task hour burndowns.
While the variability of an empirical process control like scrum may appear difficult to forecast, in this article, we’ll discuss what is necessary and unnecessary for scrum teams to understand status. We’ll also discuss how tactical status reporting, such as how the team is progressing toward accomplishing goals, can be completed in less than one minute each day.
Sprint planning
To understand how scrum teams use tactical status reporting, you have to first examine how they plan their work. Scrum teams are strategically stable, which allows them to be tactically flexible. They’re stable because they have a foundation of a clear product vision and roadmap, a release goal, a product backlog, and a long-lived, even permanent team. They are flexible (adaptable) because they progressively elaborate their work into short feedback cycles called sprints. Each sprint focuses on accomplishing the release goal in support of the product vision.
A note on the phrase “permanent team.” Permanent doesn’t mean you want team members not to pursue new career opportunities. Or that once you form a team, it can never change. What we mean is we want the team to be more permanent and enduring, rather than temporary–as stable as possible. Long-lived teams become more valuable to an organization because of their predictable velocity, cohesion with their teammates, understanding of the customer, and knowledge of the product. Long-lived teams build upon the trust gained over many sprints. This trust is hard to achieve with constantly rotating team members.
Sprint planning part 1
Part 1 of sprint planning begins by defining a customer-focused sprint goal. Next, the team pulls from the backlog those items that will help them accomplish it. The level of effort for each item has been estimated based on the item’s acceptance criteria and the team’s definition of done.
Some level of estimation is essential for planning. Each story creates a “potentially shippable” increment of customer value. Summing up all the value delivered in a sprint captures the team’s velocity or pace of development they can use as empirical data to plan how much remaining backlog they can do in future sprints. Since the same people (permanent team) is doing the same type of work each sprint, the team can make decisions on how much work they can do in the sprint based on the reality of previous sprints. Now the team can move to Part 2.
Sprint planning part 2
The next step is to figure out how to accomplish the sprint goal by defining tasks with hour estimates. Teams make adjustments to the sprint backlog and goal throughout the sprint planning session based on their confidence and comparison to previous velocity trends, and available hours vs. planned hours.
Time and planning
Time is also an important factor in planning. If the total planned hours exceed the capacity, the product owner removes a backlog item or two from the sprint backlog. If the total planned hours are less than the capacity, the team’s confidence is higher. This is called building in slack–giving themselves room to respond to what they can’t expect will happen during the sprint. They can also make adjustments if needed. During planning, you won’t assign names to the tasks. The team agrees in their estimate of how long each task should take.
How do scrum teams use task hours and story points to understand their status?
Throughout the sprint, the team uses a task board to display their sprint backlog and sprint burndown chart to understand progress toward their sprint goal. The task board helps them to see the balance between remaining work and completed work. As sticky notes or electronic cards move across the task board, they know every task and backlog item’s status. When they finish the remaining work, they accomplish the goal. Simple.
Example of a task board or sprint backlog.
Burndown charts and task boards
One common way of estimating product backlog items for long-range planning is using story points, a relative estimation technique based on the Fibonacci sequence. The burndown chart plots the remaining story points and task hours compared to remaining time. Each day, the team completes story points and tasks, burning down both lines. With a few simple calculations, the team and stakeholders can see whether the team is on or off track from reaching the goal.
On day four, for example, the team can see they’re pretty much on track, but they may need to make some adjustments since the story points are above their planned line. Since the hours are below the line, maybe there is an impediment preventing the product owner from approving a completed backlog item? Inspecting the burndown enables the team to ask questions and have a conversation to adapt and address whatever they find.
Example of a sprint burndown chart.
For the burndown and task boards to be useful, the team must update them consistently. This includes moving completed tasks and backlog items to Done and adding new tasks discovered throughout the day. The task board is fluid and accurate per their team’s working agreement because they agreed to keep it accurate. They use their daily scrum each morning as an inspection opportunity to adapt their plan every day.
Sprint after sprint of completed backlog items helps the team forecast their progress toward their release goal, as shown in this example of a release burndown chart. As the product owner approves the completed backlog item, the burndown reflects the new valuable increment. Busy executives also appreciate this view because it helps them see if the team needs help.
Example of a release burndown chart.
How can an update take less than one minute?
If the team maintains the sprint backlog correctly and daily, they simply:
- Move tasks to the correct status.
- Update the remaining time on the tasks that are “In Progress.”
- Revise the remaining time of the tasks in “To Do.” if they learn something new about the tasks.
That’s it! Your team can easily perform these steps in under a minute per day. You can update a simple burndown graph with the time remaining on the tasks (or the tool does it automatically).
Should you track original time and completed time?
No. Neither of these is helpful to the team. The team only cares about remaining work to get to done. How much time it took to complete a task doesn’t tell you whether you’re going to achieve your goal. How much work is remaining tells you that. Remember principle 10, “Simplicity, the art of maximizing the amount of work not done – is essential,” even with tactical status reporting.
Instead, focus on building an amazing product for your customers that will blow their minds!
Transparency is critical for inspecting and adapting
Transparent estimates are crucial for inspecting and adapting. As with all scrum artifacts, they inform decision-making conversations. Regardless of the status, what really matters is supporting the team and organization to adapt and better deliver products and serve customers, which is what the busy executive cares about.
Your team can conduct tactical status reporting in less than one minute each day, as long as each team member updates their task, and the team maintains their task board. Tracking original estimates and actual completed time are unnecessary. More importantly, to realize the true status of your product development, rely on sprint review conversations.
“Working software is the primary measure of progress.,” per principle 7. Let your inspection of the product increment and other scrum artifacts inform your status decision making.
Looking for support to ensure transparency in status and actionable takeaways? Our scrum experts can help. Contact us today to learn more.
