Agile teams often face a challenge in determining how long their iterations, or sprints, should be. If sprints are too short, teams can get bogged down with prep work and overhead. In contrast, maturing teams may struggle to deliver working software in the demanding timeframe. However, longer sprints may also lead to wasted time for questionable added value.
On a project, risk management means identifying, planning for, and monitoring for risks that threaten to derail the project’s schedule, budget, or scope. In agile, the risks threatening the scope take on greater dimension, since the scope is flexible. Risks on agile projects hinder the ability to deliver value to the customer by keeping the team from being able to accomplish key tasks. In this blog post, we will look at the risk-adjusted backlog and how to apply it at each level of the agile project.
The release burnup chart shows an Agile team’s progress toward their release goal by identifying the work they have completed, or “burnt up.” The release burnup chart builds on the sprint burndown chart, which shows the team’s progress toward their sprint goal by identifying the work that has “burnt down,” Burnup charts can show the effect of scope changes with greater clarity than burndown charts can; they can also be stacked to show changes from one sprint to the next. With these added features comes one precaution: burnup charts are often harder to read than burndown charts. In this post, we will discuss ways of creating burnup charts, how they would be used, and best practices and pitfalls.
The sprint burndown chart is a key tool to monitor the progress of your team during a sprint. The chart measures remaining work against time. The sprint burndown chart’s primary purpose is to show whether the team will be able to complete the sprint work. Beyond this primary purpose, the sprint burndown chart can also expose the reality of how your team is performing.
Resource allocation is a critical process on both Agile and traditional projects. Even the best-planned projects can’t be carried out if there are not enough people to do the project activities, or if they are too busy. Agile values teams delivering working software at the end of each sprint, collaborating closely with the customer, and managing their own output. To accomplish these goals, the team needs must be able to accurately assess its own capability based on reality rather than best guesses. The sprint capacity planning sheet is a powerful tool for teams to discover their capacity and deliver more realistic assessments of their ability to execute what is needed to finish a sprint.
Backlog management in Agile needs to occur at three levels. First, the product backlog contains the prioritized list of epics, features, stories, and tasks. Second, the release backlog separates the features in the product backlog into time-phased chunks, with the first release containing as many high-priority features as possible in a working piece. The granularity differs in that the release backlog only contains prioritized and estimated stories. Finally, there is the iteration or sprint backlog (hereafter referred to as sprint backlog), which is organized into stories, broken down into tasks and estimated in terms of hours, that the team can implement within the span of each sprint. In this post, we describe the sprint backlog and best practices and pitfalls for its use.
Strong communication between the customer and the project team is a fundamental ideal of Agile that helps to produce quality results that the customer can use right away. For strong communication to happen, there needs to be common ground; otherwise, the two sides are coming from different cultures and speaking what may sound like two different languages, and this makes communication difficult. User stories fill this gap by framing requirements in a way that facilitates communication between the customer and the project team, and for this reason, they are a critical piece of any Agile project. Keep reading to learn more about what a user story is, how it is structured, and how to write one effectively.
The product roadmap is a high-level vision for where you want your product to go. The product backlog follows up on the roadmap by serving as a list of features and requirements that help shape the product goal. Mike Griffiths (2012) defines the product backlog as “the ordered list of everything that might be needed for the product” (PMI-ACP Exam Prep, p. 38) and lists several categories of items typically found in a product backlog, including features to be built, functions, requirements, quality attributes, enhancements, and fixes. Building and maintaining the product backlog is key to realizing the high-level project goal, and takes the combined effort of the product owner, development team, and ScrumMaster. In this blog post, we will look further at how the product backlog fits into an agile project and how to successfully create and maintain it.
One of the starting points of an Agile project is to develop the product roadmap. The product roadmap documents the long-term vision of the product: it explains how the product is expected to launch and evolve. While the Agile process, and the Scrum process in particular, revolves around short-term periods of working product delivery in the form of iterations, or sprints, the product roadmap provides the long-term outlook that helps drive each of the sprints.
With this look at performance reporting, we end our ongoing series on “Eight Powerful Project Management Processes” series. These processes are also included in our toolkit, Essential Gear for Project Managers. We hope you have enjoyed this look at eight critical processes to project success.
