Explaining the Sprint Budget Chart

The Sprint Budget Chart maps how a team consumes its budget over the length of the sprint relative to the planned budget consumption calculated by ScrumEdge. This chart is based on three variables, the Planned Budget, Budget Used and Actual Completed.

Planned Budget

Once sprint planning is complete and tasks have been assigned to Team Members, ScrumEdge calculates the Planned Budget by assigning a percentage value to each day of the sprint.

Planned Budget:

Planned Budget = Previous Day’s Planned Budget + (100 / Total Days in Sprint)

Example: If a team is working on a 10 day sprint their Planned Budget value will be calculated as follows:

Day 1: 0% + (100 / 10) = 10%

Day 2: 10% + (100 / 10) = 20%

Day 3: 20% + (100 / 10) = 30%

…

Day 10: 90% + (100 / 10) = 100%

Budget Used

The Budget Used line shows what percentage of the the planned budget a team member has used. It is calculated every day by dividing the total number of hours burnt till that day by the total number of hours estimated in the sprint.

Budget Used (Whole Team):

Budget Used = (Total Team Hours Burnt till this Day/ Total Team Hours Estimated in Sprint) * 100

Budget Used (Team Member):

Budget Used = (Total Member Hours Burnt till this Day / Total Member Hours Estimated in Sprint) * 100

Example: If a 2 team plans a sprint where their total task estimates are 100 and burns a total of 12 hours on the first day, and 15 hours on the second day their Budget Used for the first two days will be as follows:

Day 1: (12 / 100) * 100 = 12%

Day 2: (27 / 100) * 100 = 27%

Actual Completed

The Actual Completed line shows the percentage of actual work that is completed in the sprint and is calculated only when a task is completed. The Actual Completed is calculated by dividing the total estimates for completed tasks by the total number of hours that are estimated in the sprint.

Actual Completed (Whole Team):

Actual Completed = (Total Task Estimates for Completed Tasks/ Total Hours Estimated in Sprint) * 100

Actual Completed (Team Member):

Actual Completed = (Total Task Estimates for Completed Tasks for Member/ Total Member Hours Estimated in Sprint) * 100

Example: A team plans a 100 hour, 10 day sprint. 1 task with estimates equaling 7 hours is completed on Day 2 and another with estimates equaling 3 hours on Day 3. On Day 4 a task with estimates equaling 12 hours is complete. The Actual Burn for this sprint would be calculated as follows:

Day 1: (0 / 100) * 100 = 0%

Day 2: (7 / 100) * 100 = 7%

Day 3: (10 / 100) * 100 = 10%

Day 4: (22 / 100) * 100 = 22%

Analyzing the Budget Chart

If used properly the Budget Chart can be a powerful tool. During the course of a sprint, the ScrumMaster can use the Budget Chart to see how much of the plan budget their team uses every day and how much actual work is completed based against the team’s budget consumption.

If the Budget Used line goes over the Planned Budget line, the ScrumMaster should immediately recognize that the team is taking longer to complete tasks than they had estimated. However, this does not mean that the sprint is headed for disaster. It is normal for team members to go over their estimates from time to time. A good ScrumMaster should investigate further to see if this could actually a problem later on in the sprint.

The Actual Completed line is an important indicator of how much work is actually being completed through the sprint. There may be a case that the Budget Used and Planned Budget lines match up perfectly but the Actual Completed line hovers at 0%. This would indicate that the team is using up the time they had planned to spend on tasks, but not actually completing any tasks. It is normal for the Actual Completed line to hover close 0% at the start of the sprint and pick up as the sprint moves forward and tasks are completed.

It is important for ScrumMasters to understand these trends and facilitate the team members in completing committed tasks.

Explaining Sprint Burn Rate Charts

 
The Sprint Burn Rate chart maps the average number of hours a Scrum team burns over the length of the sprint relative to the required burn rate calculated by ScrumEdge. This chart is based on two variables, The Ideal Burn and the Team’s Burn.

Ideal Burn

Once sprint planning is complete and tasks have been assigned to Team Members, ScrumEdge calculates the Sprint’s Ideal Burn rate by adding up the total number of hours required to complete all tasks in the sprint and dividing these over the length of the sprint to get the average number of hours the team should be burning each day to complete their tasks.

Ideal Burn: (Whole Team)

Ideal Burn Rate = (Total Sprint Hours / Number of Days in Sprint) / Total Team Members

Ideal Burn: (Single Team Member)

Total Sprint Hours Assigned to Team Member / Number of Days in Sprint

Example: If a 2 man team plans a 10 day sprint and their total tasks estimates are 100 hours their Ideal Burn Rate would be as follows:

(100 / 10) / 2 = 5

The ideal burn rate stays constant through the course of the sprint.

Team’s Burn

The Team’s Burn is the average number of hours the team burns every day.

Team’s Burn: (Whole Team)

Team’s Burn = (Total Hours Burnt By Team / Number of Days) / Number of Team Members

Team’s Burn: (Single Team Member)

Team’s Burn = Total Hours Burnt By Team Member / Number of Days

Example: If a 2 member team was to burn 10 hours on Day 1, 15 hours on Day 2 and 20 hours on Day 3, their Burn Rates would be as follows:

Day 1: (10 / 1) / 2 = 5

Day 2: (25 / 2) / 2 = 6.25

Day 3: (45 / 3) / 2 = 7.5

The Team’s Burn Rate changes from day to day.

Ideal Burn vs. Team Burn

The Team’s Burn when mapped against the Ideal Burn should give the ScrumMaster an idea of how many hours their team is burning every day. The Ideal Burn tells the ScrumMaster how many hours the team committed to burn every day through to course of the sprint. On the other hand the Team’s Burn tells the ScrumMaster how many hours their team is burning every day.

It’s important to keep in mind that the Sprint Burn Rate Chart does not help predict the success of a sprint. A Scrum team may be working at ideal burn levels and still not complete tasks because of incorrect estimation. However, this chart does give the ScrumMaster an idea of  how much time each team member is spending working on a sprint everyday. If a member’s burn rate is well below the Ideal Burn this chart should help the ScrumMaster raise a red flag and investigate the matter.

Similarly if the Ideal Burn at the start of the sprint is higher than the team’s overall velocity, the ScrumMaster should note that the team may have overcommitted. At this point it would be a good idea to regroup with the team and if need be, revise their sprint plan.

Rethinking Sprint Length

By Alexey Krivitsky & Ragnar Birgisson

Our project takes place in a distributed environment—the development team and product management are located in different geographical places. When we first came to the project, our job was to help establish an outsourced, offshore office for a project that had survived years of ad-hoc development with no fixed iterations and no pre-planned releases. The domain was not complex, but the poor code quality and the onsite absence (or remote presence) of the knowledge-holders made the start-up trickier than we and the project stakeholders had anticipated.

We spent the first three to four months learning the codebase (by fixing bugs and adding some new pieces of functionality). Finally we were ready to think about how we should approach our project. We knew we wanted to try an agile approach and, after much debate, we decided to try Scrum (how that came to be, how Scrum was introduced, how it should have been introduced instead, and how eventually it changed the way the company works are topics for another article or two—maybe next time).

Setting Sail for Scrum

When we first began, we chose to use four-week sprints. For our product backlog items, we used per-feature requirement documents that we called feature specs. A feature spec is typically a three- to five-page document with a feature description, main workflows, and the screenshots. Our feature specs were created by the remote product managers.

These documents worked to some extent. However, from time to time gathering the needed amount of specifications for the next sprint was difficult for the product owner. He and the product managers struggled to find the time to write the specifications. Even after they managed to write some things down, more often than not, the information they provided would not be enough for the developers to provide reasonable estimates.

The length of the sprints felt fine to the team, but management felt they needed more visible results. At the same time, we wondered if a shorter sprint would help focus the team and optimize performance. We decided to switch to the shortest duration deemed possible: a single week. We could always switch back if it didn’t work.

Some of the results of our change were positive. For instance, each week the stakeholders received more visible results. However, the drawbacks far outweighed the positive. First, the development team started to feel pressured by having to deliver every week. Second, it was quite difficult sometimes to deliver valuable functionality in a just a week’s time. Finally, the cost of starting and stopping a sprint felt quite high, both in time and emotional investment by the team.

Miles to Go Before We Sleep

After the rather disappointing results of our weekly sprints we decided to revert to four-week sprints.

Compared to the rush we experienced trying to deliver weekly, the next few months felt relaxed. As we began to adjust the process to our ideals (and our ideals to the realities), we managed to start collecting the specs earlier and with more detailed explanations for the programmers and the testers. Things were improving. However, when we looked closely at our sprint activities, we realized that instead of a four-week sprint, we’d really been doing three-week sprints plus a one week cushion for finalizing unfinished sprint tasks. This was definitely not what we wanted “our Scrum” to be.

Ahoy! I See Land

It had been more than a year since the project was outsourced. Things had improved, but were not yet where we wanted them to be. At that time, we made a fundamental change to our requirement management process: we substituted lightweight user stories (inspired by Mike Cohn’s User Stories Applied) for our mid-weight specifications.

As we had hoped, user stories increased communication between development and product management. They also raised our understanding of business needs by the team. As a result, inter-site trust and relationships improved. This, in turn, boosted the product quality (the increase in quality was also due to better planning through finer-grained user stories, a growing set of unit tests, and the increased size of the testing team).

Having achieved the conditions described earlier we decided to try out shorter sprints. What follows are the “hares” that we were supposed to hunt for by changing our sprint length. (Happily for the hare-lovers, some of the beasties are still hopping in the wild.)

• Boost the team’s performance. The team had been having a tendency to start losing focus in the middle of a sprint. To counteract this, they simply had another sprint planning meeting after the second week to find out the current status (though we used to maintain a burndown chart) and made corrections to their plans by redistributing the tasks. This was not an ideal situation.
• Get earlier feedback from the product management (user proxies) and thereby from the real clients. The user stories were usually available for review by the end of sprints. The high story-count of what had been developed within that three- to four-week period made it quite hard for management to ascertain the project quality and plan for fixes/changes for the next sprint.
• Let the company make more frequent releases. The company’s official plan was to have quarterly releases, but we wanted to provide the possibility of doing it more frequently.
• Remove planning difficulties. With monthly sprints, the product owner had to plan four weeks ahead, which sometimes was hard due to ever-changing business priorities. It was also hard for the development team—the large number of stories we had to consider made planning sessions long and energy draining.
• Learn faster. We had to wait at least four weeks to study the effect of any changes we implemented in our process. Also we often wished to make so many changes that we were not able to focus on all of them within a single sprint. Problems we identified during sprint retrospectives began to pile up in a queue to be resolved at some later stage.

Our Journey's Far from Done

So far the team has done three bi-weekly sprints. In that time, met the following goals (or captured the following hares):

• Boost the team’s performance. The teams started feeling more focused, which they like. They now also can remember most of the sprint’s user stories, which makes it easier for them to communicate their status to each other. Some of them claim, though, that if the complexity of user stories or internal system grows they will not be able to finish sprints this often.
• Get earlier feedback. This has been confirmed by the product managers: they were able to get clients’ feedback faster and obtain developers' estimates and updated plans faster, thereby reducing the whole feedback cycle.
• Decrease planning difficulties. This has been seen by all of the affected people. For Alexey (as a ScrumMaster), those planning days were the most difficult ones: too many stories to think of, too-long meetings to be kept organized. Now planning is almost as easy as the morning Scrums.
• Learn faster. Over the past six weeks, we’ve already had three retrospective meetings (compared to the maximum of two we might have had, had we followed monthly sprints) which were quite productive, and again, easy to do. The attendees were in no rush to list all known obstacles, since we knew in two weeks’ time we would be able to review it again.

The following goals have not been met so far:

• Let the company make more frequent releases. This is still a goal for the next quarter or two. Though quality has increased within the last months, it is still not possible to release the software just after any sprint without running one or two special bug-fixing sprints.

Are all of these positive changes a result of switching to a two-week sprint? No. Shortening the sprint length itself lent to the positive effect, but doing so would not have been possible without other essential changes, such as raising team motivation and moral, improving and increasing communication between product management and developers (with the introduction of user stories), and increasing internal product quality.

Should we have started with two-week sprints right from the beginning? We don’t think so. Again, we think we would have failed without those preconditions (trust, user stories, good quality, etc.) in place. By starting slowly and building these components, we were able to deliver more quickly and then naturally adjust the sprint length. After all, you must learn to walk before you run.