Agile Project Management: A Complete Guide

Why Agile?

If this white paper caught your eye, you’re probably interested adopting Agile methods for your software development team. You may already be trying Agile project management and are struggling to make it work.

What led you to Agile? Most likely, it was one or more of the following reasons:

1. You want to speed up the development process.
2. You have too much work, but you can’t hire more developers.
3. You’re having trouble tracking progress and getting feedback.
4. You want to reduce costs.
5. You’re tired of fighting fires.

Agile methodologies (Scrum, Kanban, Lean, and others) alleviate these issues through improved communication and iterative development that keeps project moving forward at a rapid pace.

Agile methods adhere to the principles of the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile teams realize that, while there is value in the items on the right, the items on the left have more value.

Benefits of Agile

By allowing decisions to be tested and rejected early, Agile reduces rework and allows your team to get more done with fewer resources—in turn, reducing development costs.

And Agile’s feedback loops help raise the visibility of progress metrics, allowing you to address problems before they catch fire.

Agile won’t make all your problems go away overnight. It takes time and practice before you’ll start to see the benefits of Agile project management. Hopefully, the basics provided in this white paper will get you there faster.

NOTE: The methods and artifacts discussed in this paper mostly come from Scrum and Kanban, two of the most popular Agile methods. While many Agile teams use these practices, enough variety exists in the Agile world that we can’t claim this is a “complete, definitive” guide to Agile.

Backlog Management

Let’s start off by looking at backlogs. Agile methodologies contain two types of backlogs—the product backlog and the sprint backlog.

An organized and categorized product backlog is the foundation of delivering what your customer needs. The product backlog is used to prioritize customer requests and keep the team focused on the project’s most important features.

The sprint backlog is made up of the features that the team selects from the product backlog and commits to delivering by the end of a sprint. The team chooses which features to add to the sprint backlog based on the estimates of work effort attached to each feature.

Product Backlog

Before your team starts delivering features, the product owner must first build a product backlog for the product or project.

If you’re starting a project from scratch, this process is straightforward. The product owner meets with the customer and end users to discuss what critical problems the project will solve or challenges the customer is hoping to overcome with this product. Depending on the project, the discovery process can take anywhere from a few hours to a few weeks to outline enough features for the first few sprints.

If you’re working on an existing product, building the initial backlog may be more complex. For example, a large legacy application may have thousands of feature requests, bugs, and other tasks that have been catalogued over the years. The problem isn’t filling the product backlog; it’s deciding which items are most important for the team to work on next.

TIP: Start by adding the high-priority features that support your release or sprint goals. This should give your team enough to choose from for the first couple of sprints.

Product Backlog Work Items

• Bugs
• Technical Debt
• New Features

Now that the features are added, you need to classify and prioritize the backlog. This may seem like a daunting task, but it goes faster than you think.

TIP: When starting out, don’t worry about organizing the entire backlog. Find and tag the high priority features and ask the development team to classify them into functional area and theme. Expand prioritization and classification to more of the backlog as needed, based on the sprint schedule.

Classification

Start organizing the backlog by classifying features into functional area and theme.

Functional area is the area of the product that a bug, technical debt, or new feature applies to. Classifying by functional area allows you to more efficiently plan sprints. For example, when planning a sprint to address a high-priority item, you can easily find low-priority items in the same functional area to include in the sprint.

TIP: Developers can help classify work items because they understand the underlying code base in the project.

Themes also help you with sprint planning by allowing you to address overarching problems. If customers struggle to navigate the app, for example, you can create a sprint that includes all features tagged with the theme “usability” to quickly address the problem. We’ll take a closer look at themes when we talk about release planning.

Prioritization

Next, the product owner prioritizes the features in the product backlog by business value. This is where the product owner’s understanding of the customer and end user is critical. Features in the product backlog should have clear business value for them to be considered for development.

Ideally, the product backlog lists the highest priority feature at the top and the lowest priority feature at the bottom. However, in the case of large feature sets, it a bucket approach may work better.

A bucket approach uses qualitative descriptions such as low, medium, and high to group features with similar priorities. After grouping the features into buckets, you can refine the buckets as many times as you want.

A word of warning about using a bucket approach: It’s easy to get sidetracked and prioritize features according to the “loudest customer” or “this week’s sales opportunity.” If you use the bucket approach, set tolerances to ensure the high-priority bucket doesn’t get overfilled. For example, you might set a tolerance of “no more than five items in the high-priority bucket.” If you add a sixth item, you must take something else out.

An organized backlog with a good classification and prioritization scheme is essential before the development team can start working on the highest value features.

Maintaining the Product Backlog

Agile practices work by delivering value to the customer in increments. Customers get the opportunity to offer relevant feedback throughout the development lifecycle, usually at the end of each sprint. Based on this feedback, the product owner prunes and re-prioritizes the product backlog.

One reason the product backlog needs constant maintenance: Customer needs change over time. One of the biggest benefits of Agile is that it lets you hit moving targets more easily than non-Agile (i.e., Waterfall) development methods. Maintaining the backlog keeps the development team’s aim true.

Implementing features can also change or eliminate the need for other seemingly unrelated features. For example, say the customer originally wanted credit card processing and PayPal integration for their app. Once the PayPal integration feature is developed, the customer may realize they can process credit cards through PayPal and drop the request for a separate credit card processing feature. The product owner is responsible removing that feature from the backlog, so that the development team isn’t working on something that’s no longer needed.

And new features get added—sometimes by customer request and sometimes because development reveals a need. This is the final reason why the backlog must be maintained. The product owner needs to vet new ideas against existing ideas to determine if they should be added to the backlog, and at what priority.

Sprint Backlog

The sprint backlog is made up of the features that the team selects from the product backlog for a specific sprint. The team commits to deliver every feature in the sprint backlog by the end of the current sprint.

It’s important for the development team to understand the level of commitment they are making as they build the sprint backlog. Meeting a sprint commitment builds trust with the customer; not meeting it erodes trust.

TIP: To help establish quick wins and build confidence, teams new to Scrum or other Agile methods should take on less work than they think they can handle in early sprints.

Once the team knows what features will go into the sprint backlog, the development team breaks the features down into tasks. Tasks should be no more than 16 hours in duration. This helps the team understand the problem better and get a good idea of how much work is involved.

The team should not take on a task until it goes to the work-in-progress column. This ensures task ownership is not predetermined and leaves tasks open for other team members to grab.

We’ll take a closer look at sprint planning later. First, we need to go over Agile estimating.

Agile Estimating

As you transition to Agile, your initial estimates will be all over the map. Even if you are an experienced estimator in other development methodologies, expect a learning curve. It generally takes several iterations, sometimes over the span of months, for your team to get good at Agile estimating.

This is an important expectation to set with your team and with management. But don’t worry—Agile allows you to fine tune your estimates as the project progresses.

Estimating on Agile projects occurs iteratively at the beginning of each sprint for features, and throughout the sprint for tasks. If you’re using Scrum, the first day of the sprint is when the two-part sprint planning occurs. In other Agile methodologies, the planning day is broken up into two parts: release planning and sprint (or iteration) planning.

TIP: Don’t start the first sprint with an empty product backlog. The Scrum Master and product owner should work together to populate the product backlog prior to the first planning meeting.

Who Does the Estimating?

During release planning, the team “sizes”—estimates the work effort required for—the features in the product backlog. Participants in this sizing effort include the core development team (developers, testers, tech writers, and others), the Scrum Master, and the product owner or customer.

The customer or product owner needs to be involved to clarify the value that the feature provides. The product owner can also provide the team with a good understanding of what they are estimating.

Only the development team should do the estimating, however, because they will be accountable for doing the work. This is a departure from non-Agile methods, where team leaders or development managers generally provide estimates.

How Estimating Works

Agile estimating is based on a point system. You can use any collection of point values you want, but the most common point range used is a limited Fibonacci sequence: two, three, five, and eight.

As an example, let’s say we want to compare the effort of building a car to that of building a bus. If we assign the car a value of two, we might say the bus has a value of five—twice the effort of assembling a car (i.e., larger than three) but less than four times the car’s effort (i.e., smaller than eight).

Points are also useful for determining team velocity, or when the amount of work currently in the product backlog will be done. For example, if there are 40 points in the backlog and the team shows an average velocity of five points per sprint, then it should take eight sprints to finish the project.

TIP: Points are only one way of estimating. Some teams prefer to use T-shirt sizes (small, medium, large) or other values to estimate work effort.

Estimating User Stories

Agile projects express features in terms of business value. One way this is done is through user stories—informal, natural language descriptions of the product’s features. User stories are written from the perspective of the end user and describe how a feature will provide value to a user.

Anyone can write user stories. The product owner makes sure the product backlog contains enough user stories, but they don’t necessarily write them.

If you’re building an eCommerce app, for example, and you want to give the user the ability to easily convert currency values, the user story might look like this:

TITLE: Currency Converter

DESCRIPTION: As a shopper, I want to easily view item prices in my native currency.

ACCEPTANCE CRITERIA:

1. Ability to convert US dollars to Euros
2. Ability to convert Euros to US dollars
3. Ability to convert US dollars to Canadian dollars
4. Ability to convert Canadian dollars to US dollars

User stories are not meant to be detailed. They’re just placeholders for the daily conversation that needs to happen between the development team and the product owner during the sprint. If you can’t fit the description of a user story on a 3”x5” index card, start over.

Story Points

User stories are estimated iteratively throughout the project using story points. During release planning, the product owner talks about new stories that have been added to the product backlog, as well as the objective for the sprint or release. If any of the new stories are likely to end up in the next couple of sprints, the team should take the time to estimate as many stories as they can within the release planning timeframe.

The team discusses each new story with the product owner until they have a good understanding of the user story and can estimate its size. The size estimate will be relative to other user stories in the sprint or release.

TIP: Use story points instead of hours to estimate the relative size of a user story. Estimating user stories in hours has the stigma of exactness or predictability, increasing pressure on the team.

Handling Complex Stories

During planning, don’t spend too much time discussing user stories that have many dependencies or unknowns. If you don’t understand the dependencies or too many questions exist about what the story should accomplish, your estimates will generally be larger to account for the additional complexity.

User stories that are too big to estimate or complete in one sprint are called epics. Product owners can use epics for planning purposes, but they should break the epic down into smaller stories before the team tries to estimate. After the epic is broken down, it is usually thrown away.

Reaching a Consensus

After you have everyone’s story point estimates, you need to build a team consensus on what the final story point value should be for the user story under discussion.

If any story point estimates are radically higher or lower than the average, ask the team members who gave those estimates why they think the user story will take more or less effort than the average. They may have misunderstood something, or they might be aware of a problem no one else has thought of.

At the beginning of the project, establish some method for determining how to move forward if there is not complete agreement. Team collaboration doesn’t mean there will always be a complete consensus on every estimate or decision. Before these situations arise, decide together how to deal with disagreement.

Estimating Task Hours

During the last part of release planning, the team removes the stories they’ve agreed to deliver from the product backlog and puts them in the sprint backlog. Then they begin planning the sprint.

This is where the development team breaks down the stories into tasks. The team then works together to assign each task an estimate in hours.

Task estimates are based on ideal hours in an ideal day. The team should estimate how long it would take to complete a task assuming they have no interruptions or meetings and plenty of energy.

TIP: Keep task estimates under 16 hours (i.e., two working days). Smaller task estimates increase the overall understanding of the problem. For example, a testing task estimated at 80 hours for a two-week sprint doesn’t break down the types of testing that need to be done.

Release and Sprint Planning

Once you’ve established your product backlog and estimated your user stories with story points, it’s time to plan how you’re going to tackle the project. In Agile, this planning happens on two levels: release planning and sprint planning. Release planning balances business value with delivery capability. The release plan establishes the release date, as well as how many sprints it will take to complete the release and how long those sprints will last. Release planning concludes with an agreement about what features will go into the current sprint’s backlog. 

Sprint planning involves creating the sprint backlog. By the time you finish your release and sprint planning, you’ll have a road map of your product’s releases. Let’s take a closer look at these two key agile activities.

Release Planning

After the product owner assembles the backlog of user stories, it’s time to sit down with the team for a release planning session. During this meeting, your team performs the following tasks:

• Review the project’s strategic goals
• Commit to the goal for the current release
• Update the goals for future releases
• Provide story point estimates for stories in the product backlog
• Create a schedule of sprints for the current release

Themes

In addition, release planning involves grouping user stories by theme. Themes enable your team to work on user stories with related functionality, allowing them to focus on one functional area at a time. This minimizes the amount of context switching the team does, which helps them get more done faster. Themes also help organize the backlog so you can quickly find items with related functionality.

From the product owners point of view, themes typically reflect some aspect of business value—a benefit to the business or customer. Themes are things like “improve navigation,” “increase security,” “meet compliance laws,” and other areas that have related features.

TIP: Not all stories in a theme will be equally important, so all stories do not need to be completed to deliver a theme’s benefits.

Setting Release Goals

The product owner should be prepared to discuss the release goals at the release planning meeting. These goals can be adjusted if the team comes up a better set of goals, or if they’re not confident they can meet the goals.

By the end of the meeting, the development team should understand the customer and business needs driving the release goals. Likewise, management and the product owner should understand the challenges involved in achieving the goals.

To help with release planning, perform the following tasks:

• Select a desired sprint length.
• Set target release dates.
• Tag the release with a goal or goals.

Release planning helps Agile teams establish a consistent release schedule, which creates a regular rhythm for the project. Everyone involved with the project, both inside and outside the team, knows when to expect a new release.

Calculating Velocity

As mentioned earlier, velocity is the average number of story points a team completes during a sprint. You can use velocity to determine when your project will be completed.

For example, if the team’s known velocity is 20 points per sprint, it should take them about 12 sprints to complete a project with 240 points in it. Velocity can be determined by looking at the past three sprints and calculating the average story points completed.

If the team doesn’t have an established velocity, have the team estimate their maximum and minimum points per sprint. For example, the team may estimate 20 points per sprint as the minimum velocity and 40 points per sprint as their maximum velocity. From there, you know your worst-case scenario has the project completed in 12 sprints; best-case scenario, six sprints.

A Work in Progress

Your initial release plan is a rough draft. You’ve got enough of a blueprint that you can get started, but you’ll need to continually revise the plan as you go. This is a key part of an Android process.

One reason for this continual revision is that takes a few sprints before you get an accurate idea of your team’s true velocity. Also, sprints won’t always deliver everything you plan for them to deliver, or they may deliver more than the plan calls for. And then there are staffing changes, customer changes, and other unforeseen problems that will impact your release plan.

The most important reason, however, is that business and customer needs change overtime, sometimes rapidly. It’s important to remain flexible about future release goals to ensure you are always delivering the highest value for the customer.

Sprint Planning

During sprint planning, the development team breaks down the selected user stories into tasks. For each task, they write down how many hours they think they’ll need to complete it.

TIP: Tasks are not assigned to an individual developer until they move to the “work in process” column of the task board. Assigning tasks as they move from “to do” to “work in progress” leaves tasks open to anyone and encourages team ownership for the work in the sprint.

The development team should break down features until they reach a natural stopping point. Don’t try to identify every single task; they will be added, removed, and updated as the sprint progresses.

The time needed for sprint planning varies depending on the project, but the average is about four hours for a 30-day sprint. Product owners usually don’t participate, because they gave their input on the sprint backlog in the release planning session.

Hardening Sprints

Hardening sprints allow teams to focus on paying down the technical debt that has accumulated over the course of the project. These sprints are especially important for large and complex projects, where technical debt accumulates faster.

Hardening sprints can be scheduled anytime in the release cycle. Rather than adding new features in this sprint, you use hardening sprints to perform stabilization, bug fixes, and testing. The result is a more manageable and maintainable codebase.

Spikes

If the team needs more information about an item, you might need to schedule a spike. Spikes focus on researching an issue or technology, with a goal of answering a specific business or IT question.

Spikes can last from a few hours to a few days, depending on the problem. For large spikes, create a user story and estimate it at the same time as other stories, so the effort can be incorporated into a sprint.

TIP: Don’t allow spikes to go on indefinitely. Limit the spike’s duration to focus the research effort and reduce the time spent on tangents.

Daily Activities

No matter how long sprints are, some basic activities need to be performed every day. These activities include:

• Holding daily standups
• Working through stories, tasks, and testing
• Identifying and removing impediments
• Monitoring issues
• Updating progress
• Updating the plan

Let’s take a brief look at each of these daily activities.

Daily Standups

The daily standup meeting is a core part of Agile because it encourages communication and updates the team on the sprint’s progress. The daily standup meeting earned its name because everyone remains standing to keep the meeting short and to the point. Daily standups should be 15 minutes or shorter and held five days a week. Pick a time that works well for all team members—the product owner, Scrum Master, and core development team.

Stakeholders, managers, customers, and others are welcome to attend and listen, but this is not a status meeting for management. Only the development team, Scrum Master, and product owners speak during this meeting.

All members of the team share brief answers to three questions:

1. What did you do yesterday?
2. What are you planning to do today?
3. What is blocking your progress?

TIP: Your team may misperceive the daily standup as their time to report to the Scrum Master. In fact, the daily standup provides a chance for the team to talk to each other. The Scrum Master only listens, provides guidance, and finds ways to facilitate the team’s progress.

The daily standup is not the time for detailed design discussions. The need for a longer discussion might be identified during the meeting, but that discussion should take place later and involve only the necessary participants.

Working through Stories, Tasks, and Testing

When you begin a new sprint, all team members should have a list of the user stories and tasks they’ve agreed to complete. Think of sprints as mini deliverables; tasks should be developed, tested, and functional by the end of the sprint.

Even though team members commit to completing a task, they aren’t locked into that task. A well-functioning Agile team knows to trade off tasks when team members start to struggle.

For trade-offs to occur, team members should be encouraged to speak up as soon as they run into trouble. The longer they wait, the fewer the options for solving problems.

Conversely, if a team member finishes a task early or has expertise in an area that others lack, it’s their responsibility to help other team members, even for tasks that are outside their usual responsibility.

The Scrum Master

The Scrum Master is a member of the team who takes on the responsibility for enforcing Agile practices and keeping the team on track. They foster close cooperation among everyone involved with the project and shield the team from external interference.

One of the Scrum Master’s key responsibilities is to help remove impediments. An impediment is anything that prevents a team member from performing work as efficiently as possible. It can range from a large issue (“I need data from another test team to test this report”) to a small hassle (“I need a new mouse”).

The Scrum Master can only be effective, however, if the team reports impediments as soon as they crop up. At the daily standup meeting, the Scrum Master records new impediments and reports on previous impediments that have been resolved.

Open Environments

Visiblity is a key Agile practice. Progress must be constantly visible to all team members, management, and stakeholders. It builds management’s trust in the team, which is needed to make the team self-organizing and self-empowered—two attributes shared by the most successful Agile teams.

To foster trust and openness, everyone working on the project must be comfortable discussing the true status of their tasks. This can be difficult for teams transitioning from non-Agile development environments, where finger-pointing and the blame game are common.

The Scrum Master must act as a “servant leader” to make this kind of open environment successful. That means the Scrum Master must “walk the talk” and model openness. They must facilitate problem solving and avoid criticizing individual team members.

Communicating Progress

Communicating progress effectively makes Agile teams successful. The responsibility falls on the Scrum Master for keeping the team’s progress updated and visible to all project stakeholders.

Burndown charts and task boards are two ways to communicate this progress.

While the daily standup provides the best gauge of progress for the team, the sprint burndown chart communicates progress to stakeholders. It’s a graphical representation of the team’s momentum, displaying the amount of work remaining in the sprint backlog on the vertical axis and the time remaining along the horizontal axis. Ideally, the chart burns down to zero by the end of the sprint. If team members are reporting their remaining task hours honestly, the line should fluctuate up and down as it moves towards zero.

The task board shows who is handling a task and what state the task is in—for example, Not Started, In Progress, or Done. It shows stakeholders at a glance who’s working on what task, and keeps them updated on the status of all items. As such, it’s a critical information radiator for Agile teams.

The task board illustrates the team’s progress toward their sprint goals, and should be easily visible to the entire project team. Originally, this was accomplished with physical task board and sticky notes or note cards. The creation of task board software, such as Trello, means you can display your task board on a large flatscreen located in a common area. Not only does task board software make radiating information easier, but it also allows you to preserve the data in case you need to refer back to it after the sprint is complete.

Monitoring Issues

In an Agile methodology, code goes into production sooner than it does in non-Agile development. Production code needs to be maintained even before the project is complete.

So how do you handle bugs and production issues? It depends on the severity of the defect and which team is responsible for maintenance support. If a separate team is responsible for maintenance support, the project team can focus on development work.

However, if the project team is also responsible for maintenance support, make sure you allow time for emergency production issues when the sprint is planned. This ensures the team will have time to handle issues that require immediate assistance as soon as they occur. For production issues that are not emergencies, the product owner will prioritize the defects back into the product backlog just like any other feature.

Establishing a triage process for production issues allows the team to monitor issues without disrupting progress. New and existing issues should be addressed in future sprints, where proper planning and prioritization by the product owner can make sure the team is working on the most valuable features and tasks.

Bugs and issues aren’t the only things discovered in production. Customers often suggest new features or have suggestions for improving existing features. These types of issues are often reported via the same mechanism as defects.

For example, users often describe a feature request as a “bug” when the software doesn’t work the way they want it to. For this reason, it’s important for the product owner to have access to production issues.

Defining Done

The definition of “done” depends on each team member’s point of view. For example, if the task is “obtain a Swiss Army knife,” you could end up with a knife that has five tools, one with 20 tools, or a monster with 100 tools. The task is “done,” but it may not be what you had in mind.

In Agile processes, releasable features are developed in short sprints, so the team’s definition of done is continually inspected and adapted, reducing the chance of disagreement at the end of a sprint.

The definition of done is determined by the team during release planning, so everyone who can be held accountable for the delivery of the product is included in defining what done looks like at the end of the sprint.

Ideally, your team’s definition of done will be consistent throughout the project. In organizations with a lot of waste, however, the definition may change over several sprints as the team becomes more efficient at producing software, and as the Scrum Master removes impediments.

There is no universally accepted definition of done for an Agile project. The uniqueness of projects, coupled with the organization’s culture, makes it nearly impossible to have a catch-all definition. That’s why it’s critical for the team to establish doneness criteria.

When defining doneness, your team will need to understand the following:

1. What are the product owner’s expectations?
2. How do other internal stakeholders define done?
3. How do external stakeholders define done?

It will likely take a couple hours to get a definition of done that everyone agrees to. Coming out of the meeting, the team will have a list of criteria which must be met before a user story is considered done. If the list can’t be completely checked off at the end of a sprint, the user story is not considered done and the work shouldn’t be counted toward that sprint’s velocity.

TIP: The definition of done may or may not change from sprint to sprint.

Communicating Done

After your team has the definition locked down, make all stakeholders aware of it. Put your definition of done on an information radiator (such as your task board) and post it in a team room or somewhere else where it will be seen often.

Remember, Agile relies heavily on trust. Transparency about what done means is absolutely critical to building trust within your team and the organization.

Sprint Reviews

After you get to done, it’s time to conduct a sprint review. The sprint review is another checkpoint to make sure the team is delivering the right product. It also promotes communication among stakeholders.

NOTE: We define “stakeholder” based on the Project Management Institute (PMI) definition, which is any person or organization that is positively or negatively affected by the outcome of project.

At a minimum, stakeholders include the Scrum Master, product owner, and development team, because they’re all responsible for the delivery of the sprint objectives and the project in general.

Other stakeholders who may attend the sprint review include technical teams that provided support to the team during sprint, such as infrastructure and architecture. The project sponsor, senior managers and executives are also invited to attend, as well as any external organizations that will be affected by the changes resulting from the project.

Pick a Driver

Before the sprint review, decide who will “drive” the meeting—in other words, demonstrate the product.

The driver should not be the same team member for every sprint. Why not? Because sharing this responsibility allows team members to show off the team’s work and receive recognition for it. Remember, the entire team contributed to the project, so don’t let the Scrum Master or product owner get all the credit by doing every demo.

TIP: Another benefit of this approach is that it helps reinforce the “servant leader” role of the Scrum Master.

The driver shouldn’t be an assigned role, either. Let the team decide who will drive the sprint review by picking a name out of a hat, rolling dice, or some other fun way. Just make sure each team member gets a chance to drive a sprint.

Transitioning to an Agile leadership style is often difficult for teams used to working together under non-Agile roles. Sharing the demo responsibilities can help the team make the change from a top-down project hierarchy, where only the project manager or senior team members get to interface with senior management.

Sprint Review Steps

Three things occur during the sprint review:

1. The product owner gives a brief overview of the objectives of the sprint or release.
2. A team member gives a brief overview of a selected user story and demos the story in the software.
3. The team answers any questions about the implementation of the story and takes notes about anything that will be valuable for the sprint retrospective.

Steps two and three are repeated for each story in the sprint.

TIP: Block out adequate time for the sprint review. For a 30-day sprint, plan on the review to take about four hours.

Incomplete Stories

Stories still in the sprint backlog at the end of a sprint are carried into release planning for the next sprint. After discussing the stories with the team, the product owner may decide not to carry a story into the next sprint, and that’s okay.

Your team should understand three things when deciding whether to continue developing an unfinished story:

1. The business value the story adds
2. The technical ramifications of deciding to stop
3. The additional support needed to continue

If your team uses story points to estimate user stories, the team does not get points for incomplete stories. Regardless of fault, the team gets points for only delivering completed stories. This reinforces the commitment to complete the work they chose during sprint planning.

Sprint Retrospective

Even though the sprint review takes place on the last day of each sprint, the sprint is not closed until the team has held their sprint retrospective.

The sprint retrospective is usually held after the sprint review, allowing the team to reflect on the entire sprint, including the review. It also gives them the opportunity to reconnect and improve the way the project is delivered.

Sometimes scheduling conflicts make it necessary to have the retrospective before the sprint review. Regardless of which way your team decides to order the retrospective and review, they should occur on the same day to allow the team to mentally close the sprint and focus on what’s coming next.

A Final Inspection

For Agile teams, the retrospective is the last in a long line of inspections that occur during a sprint. Unlike other inspections, the retrospective provides the best opportunity for the team to identify ways to adapt and improve their processes going forward.

There are three main advantages of the retrospective:

1. There’s still time to make a difference. What you discover in the sprint retrospective will be used in future sprints, making a positive impact on the project team, the customer, and product quality.
2. You almost have total recall. Team members only need to remember things that happened over a period of weeks instead of months or years, which means the gap between what they remember and what actually happened is small.
3. Energy levels are high. Teams are engaged and energized because they know the actions coming out of the retrospective will be implemented. In other words, they know that the time is well spent and not wasted on a fruitless exercise.

Who to Involve

At a minimum, this retrospective should include the core team: the product owner, development team, and Scrum Master. Supporting teams can also be invited. These would be the people who were involved in fulfilling sprint objectives, but not assigned to the entire project. Optional participants include other stakeholders, such as managers.

TIP: Project stakeholders should be invited to attend this meeting, because they often receive information generated by a sprint, such as metrics and reports. If there’s a problem with the way the burndown chart is structured, for example, these stakeholders may want to discuss the issue and come up with improvements.

Conducting the Retrospective

You don’t need to spend a lot of time putting together the retrospective. Keep it informative and useful, but it’s okay to have a little fun with it, too.

If you’re having this meeting after a long sprint review, the team might be low on energy. Consider providing some snacks to give everyone a boost. You’ll also want to set up a whiteboard and markers, some pens and sticky notes, and a large screen or projector.

Beyond that, all you need is the ability to facilitate a good conversation.

Different types of Agile have their own steps for retrospectives, but the basic steps are these:

1. Set the stage.
2. Gather data.
3. Generate insights
4. Decide what to do
5. Close the retrospective.

Divide the whiteboard into three columns and label them “What Worked Well,” “What Needs Improvement,” and “Next Steps.”

What Worked Well?

In this column, list the processes, interactions, and events that the team found helpful and would like to continue

What Didn’t Work?

List the delays, impediments and broken processes that the team would like to either improve or discontinue.

Improvement Actions

What actions can you take to improve your process going forward? List the actions that volunteers from the team, including the Scrum Master and product owner, agreed to see through to completion in future sprints. In rare cases, actions may be picked up by the entire team.

TIP: Open the next retrospective with a review of how the improvement actions from previous retrospective worked. Not all actions will work the first time, so iterate and adapt!

If the actions take more than an hour to do, the team member who volunteered for the action item should take it into the next sprint planning session and add it to the task board in the next sprint.

Progress Metrics

Metrics are important for all projects, no matter how they are delivered. They help you measure and communicate team progress and provide insight into areas for improvement.

Before you start your first sprint, make sure the entire team understands what metrics will be collected, why they are being collected, and who will be reading the resulting reports. This knowledge will help you improve clarity when reporting your team status, especially to senior management.

TIP: Depending on the project, you may be required to provide different views for different stakeholders. The use of metrics will also vary from project to project.

Information Radiators

Agile centers on sharing metrics with everyone involved in the project, because transparency builds trust. Many Agile teams use what Alastair Cockburn calls “information radiators”—in other words, highly visible ways of displaying progress reports.

The Agile Alliance defines information radiators as “the generic term for any of a number of handwritten, drawn, printed, or electronic displays which a team places in a highly visible location, so that all team members as well as passers-by can see the latest information at a glance: count of automated tests, velocity, incident reports, continuous integration status, and so on.”

Information radiators can be any chart or report used in Agile development—burn down charts, burn up charts, task boards, and so on. The purpose of information radiators is to help keep the team focused on what really needs their attention and to promote transparency.

Hard Metrics

Generally speaking, Agile projects track two types of metrics: hard and soft. Hard metrics measure the mechanics of Agile projects. How hard metrics are reported depends on the particular Agile methodology you’re using, but almost everyone uses some form of hybrid that borrows pieces from different Agile frameworks.

For example, a pure Scrum team would report progress metrics via burn down charts and burn up charts. A pure Kanban team, on the other hand, would track lead time and cycle time via a cumulative flow diagram. Both Scrum and Kanban use task boards.

Other hard metrics often tracked include defect (or “bug”) reports and build failure reports.

Soft Metrics

The metrics you won’t see on an information radiator are the soft metrics. Soft metrics track things like customer satisfaction and team morale.

Remember, two pillars of the Agile Manifesto are:

• Individuals and interactions over processes and tools
• Customer collaboration over contract negotiation

Despite this emphasis on the importance of people, most Agile teams don’t report team morale and customer satisfaction metrics to management.

Team morale is important to track because people don’t do their best work when they’re unhappy. Management should be made aware of flagging morale, so that they can step in and make changes.

The product owner is supposed to represent the customer and reflect their overall happiness. Even so, it’s a good idea to reach out to actual customers and end users to see if they’re happy with the product. The sprint review is an excellent time to measure customer satisfaction. Again, this should be reported to management, so that they make any necessary improvements to resolve customer issues. And if there are no customer issues, it’s a nice gold star for your team.

There Is No Agile

Because methodologies and frameworks have been labeled as capital-A Agile, you’ll sometimes hear developers or companies say they “do Agile”—but they don’t.

Agile is a set of values, not a single process or method. You can’t do Agile, but you can be Agile. In other words, your team either is Agile or it isn’t.

Many types of Agile methodologies exist. This white paper has mostly focused on techniques from Scrum and Kanban, but there’s also Extreme Programming (XP), Feature-Driven Development (FDD), the Dynamic Systems Development Method (DSDM), Test-Driven Development (TDD), Pair Programming, and more.

The most common form of Agile, however, is a hybrid model that borrows from one or more Agile methods and mixes what it borrows with non-Agile approaches. Few teams practice pure Scrum, for example, but they do hold standups, use task boards, and operate in sprints.

Whatever form of Agile you choose, do your research first, get buy-in from management and your team, and then stick to it. Change is seldom easy, and never happens overnight. It may be painful at first, but the more you practice it, the easier it will get and the more you’ll reap the benefits.

About Taazaa

Taazaa means “fresh.” Think new. Not canned. Tailored to you. We work with like-minded people and organizations looking for a fresh experience around creating and unleashing great software. Since 2007, Taazaa has helped hundreds of mission-minded organizations stay relevant in a world of relentless change. Leveraging custom software solutions and emerging technology, we follow design-based development practices that promote rapid delivery and a tailored fit to your business. We’re agile. We’re high-empathy and low-friction. And we make great software.

Contact Us