Skip to main content

Author: Greg Smith

The Key to Sprint Success? Your Sprint Structure

Does your team struggle to deliver sprints on time? Do you often have to split stories or determine what to do with major bugs at the end of a sprint?

The Structure of a Typical Sprint. When you understand the key activities within your sprint, you can choose a sprint length that increases the chance of consistent sprint success, with fewer bugs and fewer incomplete stories.

If so your issue may not be your process or your team but instead your sprint structure. Let’s look at this common issue in more detail. (Note: Going forward click on graphics to enlarge them).

How Did You Determine Your Sprint Length?

The current thought in the Agile community is sprint length should be somewhere between 1 and 4 weeks.

Many teams pick a sprint length based on what other teams or companies are doing or based on a length their instructor suggested during Scrum training. We often choose a length quickly because we want to get started using Agile as soon as we can.

I believe you should be more thoughtful on deciding your sprint length, as the sprint length is at the foundation of your entire Agile process.

Let’s look at ways you can choose a sprint length that will increase your chances of delivering sprints successfully on a continuous basis.

Start By Remembering What We Are Trying to Accomplish with Sprints

You are probably well versed on what sprints are and why we do them, but here is a quick review on sprint basics and how we use them to determine sprint length.

To help you determine how long you will need for a sprint, define what sprint complete, or done, will mean. Teams often keep the definition of done on a team room wall.

Sprints deliver a potentially shippable increment of software every few weeks. This does not mean every sprint has to be deployed to your production environment, but the stories should not be missing anything to make them production worthy. “Production worthy” often means:

  • Story is complete
  • Story passes unit tests
  • Story passes functional tests
  • Customer approved the story
  • Story passes non-functional tests (e.g. performance, security)
  • Story integrates with the existing code base
  • Supporting documentation is complete

How long does it typically take your team to get a subset of stories to this level of completeness? This is your first clue as to how long your sprints should be.

How Long Will You Need for Sprint Planning (at the start)?

Perhaps the most overlooked part of sprints is sprint planning. Agile teams often rush to start a sprint even when the goals are unclear. We do sprint planning because the goal is not to start a sprint as soon as we can, but rather to finish a sprint as soon as we can.

I often find that teams do high-level story point estimation and load their sprints based on how many story points they average per sprint.
In my opinion story points only tell us which stories go into sprint planning. During sprint planning the team will break down the work to the point of understanding what each functional area or individual has to do at the task/hour level. You should allocate enough time to plan your sprint with confidence as opposed to trying to start coding as soon as you can.

It typically takes 1 to 2 days to understand the work well enough to commit with confidence. Your sprint length should include the time needed to plan the sprint effectively. [Note that many companies I work with consider sprint planning to be a non-value add activity. In reality this portion of a sprint may be more important than the coding and testing. This activity ensures we are clear on what the customer needs before we begin and commit to construction.]

How Long Will You Need for Sprint Adapting (at the end)?

Most teams need 1 to 2 days to wrap up a sprint at the end. Wrapping up often includes:

 A demonstration to the customer or subject matter experts 

Determine how much time you need to wrap-up at sprint at the end, and include this time in determining your length.

  • A review of sprint deliverables and project status with key stakeholders and executives
  • A review of the team throughput (velocity) for the sprint
  • A review of new stories that were discovered during the sprint
  • A review of stories that did not get completed during the sprint
  • A review of open bugs from the sprint

If your projects or releases are not too complex, for example if you are mainly delivering enhancements to an existing platform, the adapting practices can often be completed in 1 to 2 days. On complex projects that span time zones or larger teams, sprint adapting and reviewing can run from 2 to 4 days. Adapting is considered part of a sprint so make sure your sprint length includes reasonable time for these activities.

Other Items to Consider When Determining Your Sprint Length and Structure

I often use the table below to help clients choose an initial sprint length. Note that I say initial because your first sprint will be your best indicator of whether you have chosen the correct length. If you struggle to deliver production-ready code you have probably chosen a length that is too short. This is the most common issue I see with clients. 

Use These Questions to Help You Determine the Length and Structure of Your Sprints. Click to enlarge.

The Final Product

When you have completed the steps above you should end up with a sprint structure like the one below. The structure will be dialed into a sprint length and sprint activities that set your team up for success. 

Example Sprint Structure

Feel free to contact me if you would like guidance on establishing your sprint length and structure.

Don’t forget to leave your comments below.

Seven Steps to Remarkable Retrospectives

smith May7 Img1When is the last time you went to a project or sprint retrospective and you walked away feeling like something was accomplished? Effective retrospectives are an anomaly, and we rarely walk away feeling like anything is going to improve.

In my experience poor retrospectives are due to two reasons:

      1. Attendees need time to warm up and only get to the heart of the issues as time runs out on the retrospective meeting.
      2. We have too many things to improve, so we don’t improve anything.

You can address these key issues with seven simple steps.

Step 1: Pre-Survey

Since it takes time for a team to warm-up during a retrospective, you can turn the burners on a little early by having the team complete a survey before they come to the retrospective. I suggest doing this within two days of the actual retrospective meeting. This will help the team remember the project issues before they come into the meeting, and start productive conversations earlier.

smith May7 Img2

Note: I allow retrospective attendees to respond anonymously if they prefer. My main goal is to discover perspectives on what went well and what went poorly on a project, I am not so concerned with who said it.

Step 2: Summarize the Survey and Send it to the Team Before the Retrospective Meeting.

Once you have the survey responses from everyone, summarize the findings. Since retrospective meetings often run out of time, I highlight the areas I consider most important to cover. I usually focus on two areas:

  1. An area or process that a large portion of team members have pointed out as an issue
  2. An area that everyone felt we did well on. Although we usually associate retrospectives with improving, we also want to note what we are doing well and ensure we maintain effectiveness in those areas.

Once you have summarized the survey responses and the key areas you are going to focus on, you can publish this information back to the team. By sending this to the team in advance you let them know the areas that will be covered thoroughly, even if we run out of time to discuss each survey response.

smith May7 Img3

Step 3: Start the Meeting and Go Over the Details of the Key Issues

Start your retrospective meeting by reviewing issues that the team emphasized in their survey responses. Often the discussion will lead to a deeper and more consistent understanding of what went wrong. I often have a comment area for each question on my surveys, and the comments can help start the dialogue as each item is discussed.

smith May7 Img4

Step 4: Finalize Your List of Most Important Issues to Resolve

Assuming you have a 2 hour meeting for your retrospective, you could spend the first hour going through the detailed issues, and then you could spend 30 minutes boiling the list down to 5 or 10 issues that had the most impact on the project or sprint. Figure 5 shows a top 10 list of issues that the team has reached agreement on.

smith May7 Img5

Step 5: What are the Root Causes?

If you are a business analyst you know that we are often asked to address a specific need which is really a symptom, and not the true root need or issue. The same is true in retrospectives. We may come up with a list of issues and try to solve each one, but if we look a little deeper we can often see root causes for each item. In our list of ten items, the team has discussed each one from a “peel the onion” perspective, and they have identified 5 root causes. You can see the root causes they uncovered in Figure 6.

smith May7 Img6

Step 6: Use Pareto Analysis to Find the 80/20 Root Cause

Are you familiar with Pareto Analysis? You may know it better by the common term used for it, the 80/20 Rule. The 80/20 rule states that 80% of all of our issues are caused by 20% of our root causes. In our example, the team has identified 5 root causes. In theory one of these root causes (20% of the 5 in in total) is responsible for 80% of our issues. In our example the team has cross referenced each root cause to the issues it correlates to, and found that one root cause, distributed team members, is associated with 80% of our top 10 issues.

This would tell the team that if they can only address one item in the forthcoming sprint, that item should be distributed team members. The return on investment will be the highest if we resolve this one root cause.

smith May7 Img7

Step 7: Identify Corrective Actions for the Forthcoming Project or Sprint

Once you have identified one root cause, such as distributed teams, you can have the team brainstorm on corrective actions. I usually do this in the last 30 minutes of a 2 hour retrospective meeting. In figure 8 you can see two changes the team is going to make to address the main root cause (distributed teams) that is impacting team performance.

smith May7 Img9

When I walk team members through the process covered in this article, they will often tell me “good job of identifying things to change, but we will get busy on the next sprint and forget we are supposed to make these process changes.” I agree.

So how do we prevent all of this good retrospective work from falling through the cracks? We prevent out of sight out of mind by ensuring transparency on these improvement items. My suggestion is to add tis improvement list to your Scrum wall, so people see it every day during the daily standup meeting. If you do not have a team wall, I suggest option # 2, demonstrated in figure 9.

smith May7 Img8


Retrospectives tie up valuable resources for your team. Do everything you can to make sure value is obtained from your retrospective. Avoid letting the meeting turn into a complaint and venting session, and concluding with nothing tangible. If you follow the process outlined in this article you should be able to drive improvement into your projects, which in turn will increase the enthusiasm and contribution in your retrospectives.

Don’t forget to leave your comments below.

Are You Writing Checks Your Team Cannot Cash? Here’s How to Stop Over Committing on Sprints

Smith Feb27 IMG01One of the top 5 mistakes Agile teams make is to over estimate how much work they can deliver in sprint.

Is this due to customer pressure, a desire to please, a hero mentality, or pressure from a manager? I see all of these items being a factor, but I believe the main issue is a lack of knowledge. Specifically, teams are bypassing a critical process, sprint planning.

In my experience teams often talk about story points and how they use them to estimate project releases and sprints. You can see how story points are used to create release plans in my previous article here.

Click Image to view larger.
Smith Feb27 IMG02
The disconnect usually comes from the fact that Agile teams often assume that story points are the only way you estimate how much work can be completed in a sprint. In reality, story points are only used to determine which stories to take into sprint planning. At the conclusion of sprint planning we have identified and estimated all known tasks needed to deliver each story, and we compare that to true team member availability.

Click Image to view larger.

Smith Feb27 IMG03

At this point the team makes the decision on whether the work will fit, and whether they will commit to the stories scheduled for the sprint. They have much more detailed information to make a commit decision with. Whereas story points indicate impact to the whole team, sprint planning identifies impact to each individual or functional group.

To understand this better, let’s look at an example of how we do sprint planning.

Sprint Planning Overview

If we go back to my previous article, we had a release plan based on how many story points we believed we could complete in a sprint. See figure 1.

We estimated story point velocity to be 25 points per sprint, so each sprint has 25 points or less assigned. In sprint 1 we assigned 22 points that tie directly to 4 user stories. At this point most teams stop. The team assumes they can do the 4 stories and they start sprint 1. This is a huge reason why teams over commit on sprints.

Story points are used for high level estimation and for long term planning. They are a starting point in the planning process and they make perfect sense for estimating how many sprints will be needed for a project.

They estimate effort needed by the whole team.

But if the team is going to commit to a sprint, meaning to provide a personal promise, then they should understand what they are personally being asked to deliver before they make a commitment. We do this by performing detailed planning for a given sprint.

The steps for detailed sprint planning are:

  1. Identify the stories to bring into sprint planning
  2. Design each story
  3. Identify and estimate the specific tasks for each team member
  4. Determine team member availability during the sprint
  5. Compare the task estimate to team member availability
  6. Team makes a commitment based on whether the work fits

Let’s look at each step.

Sprint Planning in Detail

Step 1: Identify the stories to bring into sprint planning.

This is relatively easy. The release plan you have already created indicates which stories to plan for the sprint.

Step 2: Design each story

Smith Feb27 IMG04

Designing a story usually means finalizing the coding approach and the visual design. An overall, high level design for the project was created during release planning. Sprint planning builds on this foundational design, with specific details for each story. If you are familiar with JAD (Joint Application Design), you will find sprint design work to be very similar. You will leave sprint planning with detailed screen, coding design, and acceptance criteria for each story.

Step 3: Identify and estimate the specific tasks for each person

After the design is finalized, each team member should identify their tasks, and how much work they need to do to support each story. Here is what the task list and estimates might look like after planning all of the stories in a sprint. See figure 3:

Click Image to view larger.

Smith Feb27 IMG05

Step 4: Determine team member availability during the sprint

Once we know how much work is needed, we need to determine how much time each person truly has available to work on the sprint. To keep our example simple, we will assume that our example team performs one week sprints. One week usually means 40 hours of work. So for each team member we should have 40 hours for each of them to deliver their tasks. If you look at the task estimates in table figure 3, no one has more than 34 hours of work to do, therefore we could assume that the work fits and we can start the sprint.

But in the real world we know this is not true. We have vacation, illness, production issues, training, company meetings, and so forth. In sprint planning we do not pretend these issues do not exist, we bring them into the availability equation. Figure 4 shows the true availability for our team in the week targeted for the sprint.

Click Image to view larger.

Smith Feb27 IMG06

Step 5: Compare task estimates to true team member availability

Now if we compare the work needed to the actual time available, we can see if the work fits. See figure 5.

Click Image to view larger.

Smith Feb27 IMG07

In our example it looks like Sanjeev’s work should fit within his availability, Keith’s work, loads him up to his capacity, Diane’s work should fit her capacity, and Paul is 9 hours short of the time needed to do his work.

Step 6: Team makes a commitment depending on if the work fits

Once we have the information in figure 5 we would share it with the team and then each team member can say whether the work will fit into their availability. The table is only a tool to help with the decision. A team member can disregard what the table implies. For example, Sanjeev could state that he does not think he can complete all of his work within the sprint, even though the table implies he has capacity. Conversely, Paul can decide to go forward with the work, even though it looks like he is 9 hours overbooked. Paul might explain that there are economies of scale, and some tasks are easier to do if he is already in the code doing work. So he will commit to the work even though the table implies he may be overbooked.

Ultimately, the decision to commit is a team decision, and if the team does not support the workload, we remove stories or tasks until they can commit.


Many Agile teams do not break their work down to the task level, or review their availability, before they commit to a sprint. By skipping this step they often overload a sprint and end up delivering short. If this becomes a habit, the business and stakeholders will lose faith in the team and their ability to deliver. Take the time to do sprint planning and increase your chances of completing your sprint on time.

Don’t forget to leave your comments below.

Your Car Can Show You How Agile Estimation Works

SmithJan23 Img01I obsess on watching the mileage my car gets. Every time I fill the tank I note how far I traveled on the last tank, and then I try to break that record with my new tank of gas.

As I have experimented with trying to get more from a tank of gas I have learned one key thing: The only part of the equation that is a constant is how many gallons of gas my tank can hold. How far I get on a tank of gas can very significantly depending on the kind of trips I go on.

For instance, if I strictly take my daughter to school via the freeway, I get really good mileage, but it is a 15 mile trip each way.

If I make a trip to the grocery store it is only 2 miles each way, but it is in the city and I have several stops and delays on the 2 mile journey. I burn a lot of gas sitting at redlights.

If I go to the airport it is about 10 miles, and also on the freeway without any stops.

I started watching my gas gauge and miles remaining after each trip. After a while I was able to identify patterns and categorize my trips into the impact they had on my tank of gas. Chart 1 shows the impact by trip type.

SmithJan23 Img02After I identified the patterns, I started wondering if I could assign a weight to each type of trip. The weight would tell me the impact each trip had on my tank based on a weighted scale.

To do this, I decided to establish trip points. I would rate each trip with a weight that correlated to its impact to my tank of gas, and it’s relative size to the other trips. Chart 2 shows the system I came up with. (note that trip points are not directly correlated to miles traveled)
SmithJan23 Img03If you review chart 2, you can see that I believe a gas station trip hits my gas tank twice as hard as a trip to the grocery store, and a trip to the airport hits my gas tank twice as hard as going to the gas station, and so on.

SmithJan23 Img04Using this scale I created, I started measuring how many total trip points I was getting per tank of gas. After running through approximately 3 tanks of gas, I saw that I averaged 40 trip points per tank. The types of trips I did could vary, but consistently I saw that I was out of gas when I was around 40 trip points. In essence, a tank of gas was worth 40 trip points.

Using this information, I decided to forecast how many tanks of gas I would go through based on the trips I anticipated taking in the future. I created a diagram that shows how many tanks of gas I will need. Note that each trip has its estimated trip points listed to the left. See the diagram below.
SmithJan23 Img05When I was done, I could see that I would need 4 tanks of gas for my forecasted trips.

So how could we correlate this approach to software project estimation?

First, in software development, our “trips” are user stories. And similar to the process we used on trips, we have the team look at each user story and determine its impact to a sprint. In software development, a sprint is our “tank of gas”. Let’s look at an example. SmithJan23 Img06

If we were building an online auction system, our list of user stories might look like the stories displayed in list 1.

And similar to our trips, each story could be sized. We size trips by distance and trip complexity (number of stops, terrain).

We size stories by the amount of code we expect to write and test, and how complex each story is (does it requires an interface? Have we ever written this type of code before?).

Table 1 below shows how a team could have went through and sized our list of stories for a project, based on how much coding and testing the story will need, plus the complexity of the story. The team discusses each story and based on their perception of coding/testing size, and how complex the story is, they establish story point values for each story.
SmithJan23 Img07Story point values are our estimates for how much impact each story will have on a sprint. So once we know the size of our stories, we need to know how many stories we can get from a tank of gas. For software teams a tank of gas is a sprint.

In our example, we would ask the team to go through a few sprints so we can determine how many story points they would average per sprint.

A team does this by typically guessing, usually a quick discussion, of how many stories they think can complete in a sprint, and they do the sprint to see how many they can actually complete. After a few sprints they usually have a good average they can use for future planning. In Agile terms we call this average throughput per sprint velocity.

For the purposes of this article, we will assume this team has worked together before, and they know how many story points they average as a group. For our example, we will say they usually average 24 story points completed in a sprint. So the team plans each sprint, so that it holds no more than 24 story points. They do agree to make an exception in sprint 3, and allow 25 story points to be assigned to that sprint. You can see their plan in the diagram below.
SmithJan23 Img08When teams assign stories to sprints, the Agile term is called creating a release plan.

Hopefully this example made it easier for you to understand how high level, relative estimation works in Agile projects. Feel free to drop me an email or leave comments if you have a question.


  • On an actual project we would probably use the Fibonacci sequence for our story point scale.
  • On a real project we may have a rule that any story larger than 8 points must be broken down into smaller stories.
  • Agile story point estimation is dependent on constants. Just as your trip computer does not expect the size of your gas tank to ever change, estimating story point requires that your team size and sprint length stay the same. If you change either item you must run a few sprints again to reset your baseline for story points you usually complete in a sprint.

Don’t forget to leave your comments below.

The Problem with Red, Yellow, Green Project Status

Many years ago I worked in a Project Management Office at a large financial institution. Once a week I prepared a project status report for executive management and the PMO director. I would calculate how we were tracking to budget, list any major issues or risks, and summarize overall status.


I was also told to mark the project as red, yellow, or green – using the following definitions:

Red: Serious issues and the project will probably be delayed or have significant budget overrun.
Yellow: Potential issues with schedule or budget, but both can probably be saved with corrective actions.
Green: On schedule, on budget, all good.


The red/yellow/green approach seems simple and logical. You only worry stakeholders if something goes wrong, so green projects do not need much review or attention.

Related Article: Starting at Red

However, in my experience the color approach has many shortcomings and potential repercussions. Let’s look at few.


What happens when a green project turns yellow or red? In my experience there is an emotional conversation with stakeholders. Here are some of comments I frequently hear when a project goes from green to yellow:

“What went wrong?”, “Why didn’t you manage this project better?, “How can we avoid this happening again?”, “Why didn’t you see this coming?”.

As a project manager I often feel great guilt with these conversations and I too question my competency. But if we spend a moment and work our way through the guilt and emotion, we can see this issue from a more analytical perspective.

Not in line with normal project uncertainty

You may be familiar with the cone of uncertainty. The cone of uncertainty tells us that you cannot completely understand all of the tasks and potential issues within a project, at the beginning of a project.


As the project progresses we learn more and there are less risks,  but we can never anticipate everything that could go wrong until the project is 100% complete.
When we label a project as green we are telling the sponsor everything is OK, today.

Sponsors interpret green as everything is OK today and it should be for the entire project. It is human nature to assume the project is under control and should stay under control.

A Different Approach

But since any experienced project manager knows that green does not necessarily mean green forever, we need to speak in verbiage that stakeholders can relate to. To address this issue I have changed my color scheme when working with sponsors and removed green from my status options.

My options are now:

Yellow: The project does not have any known issues but there is still high risk that something could go wrong (as demonstrated by the cone of uncertainty). As with any project in flight, we are managing it cautiously and we are doing our best to deliver successfully.

Orange: An issue has surfaced and the project goals are in jeopardy. We are triaging the issue(s) and at this time we believe we can still be successful
Red: An issue has surfaced and we do not believe 100% project success can be obtained due to the discovery. More than likely we will either miss the desired date, or exceed budget, or not be able to deliver the desired scope by the target date.


What do you think of my approach? I welcome your thoughts. I know many stakeholders will “freak-out” at seeing no greens, but I believe all projects are yellow until they are delivered.  We need to teach stakeholders that this a reality of doing business.  

Don’t forget to leave your comments below.