There are times on a scrum team when things don't go quite as planned in a sprint. Sometimes things get in the way of accomplishing tasks and the estimated time remaining on tasks either stays the same or rises. It's not an uncommon circumstance on most teams. However, when burn-up happens, we need to understand what's going on with the team and how we can address it to make better forward progress.

Burn-up is usually an indication that task estimation is not as accurate as is desired. There are other issues that can cause it as well, but estimation is usually the biggest. The whole reason we do the Scrum process is so we can get feedback on a short interval and we can learn from our small mistakes. We then can get better at what we do, increasing our velocity and reducing the estimation errors as quickly as we can.

Here are some of the things to watch out for which I have found cause burn-up to occur - and what can be done about it.

• Poor estimation - this is a big one. After all, estimation is one of the big reasons we do Scrum...
• Estimates are too low, because tasks were not broken down into small enough pieces.
• When sprint planning is cut short or not enough emphasis is put on analyzing the story by the team, some things can get missed. Encourage the team to take the time to think carefully through the story and do a bit of design and a bit of architecture for the story so it will be clear what needs to be done to complete the whole thing. Estimates for tasks should be in hours, and ALWAYS be SINGLE-DIGIT. If your team is taking a different approach - this could be a warning sign.
• Unclear/Misunderstood story
• If a story is vague or too complicated, it will be difficult to break down, and estimation will typically miss lots of things that will expand the estimates as they are discovered. I have seen the teams gloss over some complications just because they are scared to deal with it in sprint planning - fearing it will eat lots of planning time. Avoid the complicated stories - think in thinner "slices" of functionality. Make sure that everyone is clear on the terminology used, and that it's the customers vernacular. Everybody should be speaking the same language and one term should mean the same thing to each team member and customer alike.
• Poor acceptance criteria
• Acceptance criteria are critical to successful estimation. Spend at least 1/4 of the sprint planning time on discovering and documenting the acceptance criteria for stories - up to half the time if really needed. The acceptance criteria are really THAT important.
• Leaving things out
• Teams tend at first to see and estimate only the mainline development tasks. If a team is constantly missing estimates for stories, emphasize having a DONE list that enumerates what it takes to complete a story. Include tasks from the DONE criteria in the story tasks if they are being forgotten. There are those who might disagree, but I think there is nothing wrong with having lots of repeated sets of tasks for each story, if it accomplishes the goal of better estimation. Add test/qa tasks too if they seem to be getting left out of the estimates/
• Work on items not in the sprint backlog. This is a big one also.
• People are being randomized with tasks not on the backlog. This kind of thing is not supposed to happen, but it does. The world is not a perfect place - so be it. When these tasks happen, get them on the backlog! Don't slip them in under the covers. Even (and especially) if the tasks are not related to delivering the software - get them and their hours in the sprint backlog. At the very least they can be covered in the retrospective and they will be brought out into the light instead of being hidden.
• Production problems. This is a tough one. It can't always be estimated or guessed at. But, most teams budget a bit of time each sprint for production support. Call it a spike, or time-box the estimate at a certain percentage of the sprint's total hours. This may not be accurate, but at least we can account for it with a place holder. Production problems are usually a process smell anyway, but that discussion will occur elsewhere...
• Extra management-added tasks. A Scrum master should be insulating the team from these kinds of changes. Scrum master needs to better negotiate with the management that is adding tasks and explain to them why issues like this can derail a team.
• unforeseen meetings. Sometimes meetings are important and required, and aren't known at sprint planning time. A Scrum master can negotiate for these not to be attended by the team or at least part of the team. The Scrum master can at least explain how these meetings stall progress on delivering software, and make the case for comparing the software delivery value for that time to the benefit of attending the meeting. In most cases software delivery wins...
• Out of the office or illnesses. These can't be predicted. If they occur on a regular basis, a Scrum master can take an educated guess at what these absences might be and enter an actual story for it. While I don't particularly like this approach, when it is on the sprint backlog, it does get visibility for the issue.
• Work items that weren't estimated in planning. Are things like extra features or enhancements being added to existing tasks? If it wasn't asked for specifically, it shouldn't be written. Good acceptance criteria here would be a great yard stick to determine if these work items are really relevant. Make sure as a Scrum master that you are keeping the team focused specifically on the exact functionality to be delivered.
• Team members not updating the remaining hours
• This is a relatively common but easy fix. I like to remind people just before stand-up to make sure to update the sprint backlog with today's estimates on time remaining for tasks that are in-progress or not yet started. Every day we know more, so we should be able to fine-tune estimates as we go along. We depend on these changes to make our sprint backlog burn-down as we work.

Scrum specifically states that we should not be working on anything that isn't specifically mentioned in this sprint's backlog. There are however, practical issues that come about which will almost certainly require us to be flexible on this point.

If we use these points as indicators and even as alarms, we may well be able to keep our teams on track and deliver more software functionality to our customers.