The what

Agile is an approach to project management in which large projects are broken down into many dynamic phases called “sprints.” Each sprint spans a defined amount of time and encompasses work that goes through all phases of a traditional development lifecycle (design, develop, test, deploy, review), albeit on a smaller scale (see figure 1). Sprints contain portions of prioritized work that collectively are achievable within the sprint’s time frame.

Figure 1. Sprint cycle

Generally, a sprint will start with a planning session in which the team discusses what work should be completed in the sprint.

Regular check-in meetings are held during the sprint so that team members have time to discuss what they’re working on and to communicate any roadblocks they have encountered or expect to encounter.

Sprints conclude with a retrospective in which the team discusses what did or did not work well during the sprint. This also serves as a valuable time for managers to gauge the overall health of their teams, including getting a feel for individual engagement. 

The why

I’ll admit that Agile looks like it will just add to your team’s workload. However, it comes with some significant benefits that can increase the health and overall productivity of your team.

Testing and deploying more regularly is efficient.

With a large project, features will often be developed but not immediately tested. As more features are added, the overall amount of effort that needs to go into testing increases as they begin to pile on top of one another. Furthermore, if too much time has passed, testers will need to spend additional time becoming familiar with the original purpose and expected behavior of the feature.

This issue is eliminated with the abbreviated lifecycle in a sprint. Because testing happens immediately after implementation, it’s a simpler process. It also means that features are developed, fully tested, and then released to those who need them in a much shorter time frame.

Check-in meetings promote collaboration among team members.

Increased collaboration among team members will increase team comradery and synergy and reduce time spent on tough problems. It’s normal for individuals in a team to specialize in different areas. Regular communication will allow one team member to easily help another team member when it’s in an area of their expertise.

Sprints help prevent muddied priorities.

When you’re bombarded with requests from all directions, somehow everything seems urgent. And to be fair, sometimes it is. But it’s always helpful to be able to take a step back and analyze against what’s already on your plate.

Because sprints contain only a subset of overall work, you can compare unexpected work against the current sprint to quickly determine its priority. Ask yourself, “Is this worth putting off something on this sprint for?”

Sprints help individuals focus.

Because Agile incentivizes diverting unexpected work to the next sprint, there is less variability for individuals in the team. This helps them plan and focus better on their work.

Teams are more responsive to changing requirements.

The iterative nature of completing sprints means that a team is already positioned to handle new or shifting requirements. If something changes, the work is simply laid out and put on the next sprint. There’s no need to re-plan large portions of the project to include the changes. The changes are also addressed much faster, because of a sprint’s shorter time frame.

Managers get to see what their teams are capable of completing.

Because sprints need to be planned with feasibility in mind, you will ultimately develop metrics that allow you to know how much work can be completed within a sprint (and therefore a span of time). This means that you can more effectively estimate time frames at a larger scale and communicate those estimates to other teams and/or management.

On the extreme end, having an idea of what your team is capable of is important in determining when to communicate that unrealistic expectations have been made.

It’s easy to celebrate accomplishments.

Everyone likes to see their accomplishments. It’s a reminder that they are contributing to the team and producing value for the company. Unfortunately, it’s all too easy to lose sight of these. But, because Agile requires work to be split into small pieces and closely tracked, it’s easy to go back and see all of the things that each team member has accomplished. This means that big victories can be celebrated and tracked—and maybe even provide grounds for a promotion.

The how

Moving to Agile development can happen as slowly or as quickly as makes sense for your team. You could jump in head first and start going through all of the sprint “ceremonies” right away. But you don’t have to.

Figure 2. Sprint ceremonies

Easing into the change by introducing new processes gradually can be beneficial because it reduces the possibility of teams and/or individuals getting overwhelmed. Add a new process every week. Or every couple of weeks. You’ll still get there. As a rule of thumb, if the team is already very busy on their old development method, don’t introduce a bunch of extra processes all at once. Start small.

You may be thinking “OK, all this is great, but how do I get there and where do I start?”

Start by creating “bite-sized” pieces of work.

Agile development is dependent on having small, accomplishable portions of work. This means taking a much larger project and splitting it into many separate pieces. Ideally, you want your portions of work to be as small as possible without causing individuals to step on each other’s toes while working on them.

For example, let’s assume you have a project to create a new web page on an existing website. Instead of having a single portion of work to create the page, it could be split into many portions. For example:

• Design the page.
• Create text content for the page (once design is complete).
• Create graphics for the page (once design is complete).
• Put together the page (once text and image content are created).
• Test the page (once page is put together).
• Release the page (once page is tested).

Schedule regular check-ins, or “stand-ups.”

Schedule a regularly occurring meeting to discuss work with the team, with all team members present. The goal is for individuals to focus on things that they are or foresee themselves struggling with so that the team can provide input. This could highlight the need for collaboration or cross-training.

These meetings should be short and sweet, ideally no more than 15 minutes in length, which is why they are often referred to as “stand-ups.” Many Agile teams meet daily, but the cadence should ultimately be what works best for your team.

Develop a scale to track effort, or “story point” values.

The core foundation for any Agile team is its scale for tying a portion of work to the effort required to complete it. The scale will ultimately be the metric by which you track everything—how much work was planned for, how much was completed, how much the team can reasonably complete within a span of time, and so on.

As a baseline, decide on a numerical scale. These numbers will correspond to the amount of effort it takes for an individual to complete a portion of work. Commonly, the Fibonacci sequence is used (0.5, 1, 2, 3, 5, 8, 13, …), and it’s assumed that each number on the scale is equivalent to the effort of the two numbers before it. It’s important to note that these numbers shouldn’t correspond to anything concrete, as that tends to hinder effort-related conversations between individuals with different specialties and/or experience levels. That last thing you want is your newbie feeling bad about the fact that something that would take you an hour will take them four.

Once you’ve decided on the scale, go through some portions of work to establish which numbers on the scale correspond to them. Expect the conversations to be something like “This feels like a 1 to me.” Or “If that’s a 3, then this is a 5.” If there are disagreements, it’s usually better to overestimate than to underestimate.

Make sure to note these values on your portions of work as estimated values.

Handle future estimation in refinement sessions.

In developing your scale above, you’ve essentially done your first refinement session!

As time allows or is necessary, schedule meetings with your team to estimate effort on additional portions of work. The goal is to eventually have all portions estimated, or at the very least, to have an estimation for all portions of work that are being actively worked on.

My team does regularly scheduled refinement sessions around the start of a new sprint.

Introduce sprints.

First, you need to decide on a cadence. Many Agile teams start a new sprint every two weeks. It’s long enough that you aren’t devoting time each week to sprint planning and retrospective meetings, but also short enough that the team remains responsive to shifting requirements. That said, if your team works in an environment in which requirements constantly change or don’t change very often, you can always opt for shorter or longer sprints. You could even change them partway through, or as the need arises—my team always has a long sprint right around the holidays to accommodate vacation schedules.

Once the cadence is set, it’s time to plan your first sprint!

Using the estimated effort values on each portion of work (that were previously set in refinement sessions) as a guide, begin assigning work to the sprint. The goal for planning is to include only as much work as can be completed within your sprint time frame, starting with the work that is the most urgent. The amount of effort each team can complete is variable— it could be a 10-point sprint or a 50-point sprint depending on your effort scale or the length of your sprint. If you came up with your scale a while ago, then you may already have an idea of the number to shoot for. If not, that’s fine. Make a rough estimate and see how it goes—you might be surprised!

Also make sure to set expectations with your team on what is or is not a successful sprint. In the vast majority of cases, due to shifting requirements, it is not realistic to complete all work on a given sprint. You should be able to complete a significant percentage, though.

As a small aside, it’s been helpful for my team to plan for an additional amount of work on top of what is “normal.” For us, this is an additional 25% on top of our effort estimation, but we consider 75% complete at the end of a sprint to be successful. This gives us an incentive to push the limits, without the drop in morale if we don’t reach it. Of course, it’s celebrated when we do.

Review the sprint and track key metrics.

At the end of each sprint, it’s important to meet with the team to talk about all of the completed work.

This is an opportunity to be filled in on things that you might not have been involved in. It also helps to inform team members of each other’s areas of expertise: “Oh, you worked on that? Now I know who to ask if I have an issue in the future.”

It also should be used to revisit the effort estimates that were made at the beginning of the sprint. Each completed portion of work should be given an actual (as opposed to estimated) effort value. Inevitably, some portions of work will be either less or more difficult than what was originally estimated. This process allows future estimations of related work to be more accurate.

Finally, once the actual effort values are available, you have all the metrics needed to plan future sprints more effectively. You know how much work was completed in the span of a sprint, and looking at the difference between the estimated and actual values, you can account for your team’s average overestimation or underestimation. Other metrics can be helpful too, depending on the team’s goals.

Whatever your goals, it is useful to track all sprints, not just the most recent one, and use the average across all of them to guide your planning. This will gracefully handle inconsistencies between sprints as you complete more of them.

Have your first retrospective.

Every sprint should be concluded with a retrospective. The retrospective provides dedicated time for the team to discuss what did or did not work well, either at the team level or the individual level. This is not an analysis on the portions of work themselves, like in the review, but instead focuses on process. For example, maybe team communication was particularly beneficial during the sprint. Maybe the team could have benefited from better communication. The purpose of the retrospective is to help identify these types of things so the team can be more efficient in the future.

The most common retrospective format for these discussions is the “Start, Stop, Continue” format (see Figure 3), in which individuals identify things that could be done but weren’t, things that shouldn’t be done but were, and things that were done that should continue to be done. Even this simple format has a habit of highlighting areas of strength and ones with room for improvement.

Figure 3. The Start, Stop, Continue format

You can mix things up too! Different retrospective formats can help individuals think of different things.  Try tailoring retrospective content to what your team is working on. Interested in gauging morale? Try a retrospective geared toward how individuals feel.

Iterate, iterate, iterate!

And then, you begin again. Plan the new sprint, do the work, review the sprint, have a retrospective, and do refinement sessions whenever you need to estimate new work. That’s it.

Conclusion

Over time, your team will fall into a rhythm. The metrics collected at the end of a sprint will ensure that your effort estimations continue to get better. You’ll get faster at estimation, planning, reviews, and retrospectives. Most importantly, you’ll be fostering a healthy and positive environment that sets realistic expectations and promotes collaboration.