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:
- You want to speed up the development process.
- You have too much work, but you canât hire more developers.
- Youâre having trouble tracking progress and getting feedback.
- You want to reduce costs.
- 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:
- Ability to convert US dollars to Euros
- Ability to convert Euros to US dollars
- Ability to convert US dollars to Canadian dollars
- 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:
- What did you do yesterday?
- What are you planning to do today?
- 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:
- What are the product ownerâs expectations?
- How do other internal stakeholders define done?
- 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:
- The product owner gives a brief overview of the objectives of the sprint or release.
- A team member gives a brief overview of a selected user story and demos the story in the software.
- 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:
- The business value the story adds
- The technical ramifications of deciding to stop
- 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:
- 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.
- 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.
- 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:
- Set the stage.
- Gather data.
- Generate insights
- Decide what to do
- 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.