SM / PO Cheatsheet: Simple guide to the difference between a Scrum Master and a Product Owner

By Edward Scotcher

This is a simple one page aide memoire that can be used to help explain the responsibilities of the role of Product Owner and Scrum Master. It's great to print off and hand out to people when you are explaining what the roles are and what the differences are between them. So next time you need to talk about these roles, you can use this as a basis for a simple discussion or presentation.

Scrum Master's Responsibilities

• Responsible for helping the team deliver work to the Product Owner
• Makes sure the team can meet its commitments by removing any impediments they face, including Managing dependencies, escalating blockers that they cannot remove themselves
• Facilitates process & meetings (eg Reviews, Stand Ups, Planning, Estimation, Scheduling, Prioritization)
• Makes sure the team is fully functional, productive and improving quality
• Shields the team from distractions and interferences (including the Product Owner)
• Enables close co-operation across all roles and functions, removes barriers
• Responsible for reporting progress, including producing standard outward-facing artefacts
• Manages Product Owners expectations of the team
• Responsible for keeping time and quality requirements

Continue reading this article.

Ouija Board Estimation: A fun technique for agile estimating

By Paul Goddard

During a recent training course I ran, one of the delegates made a joke about the nature of agile estimation in Scrum teams resembling a "séance"; whereby the team gathers around the table and stares at a number of user story cards expecting something unnatural to happen. How true!  This gave me an idea for a different type of iterative estimation that I tried in practice with ‘Team Woodstock’.  I sat the team around a table and wrote the Fibonacci sequence’s numbers “1,2,3,5,8,13” and a “?” on post-its around the table in the design of a Ouija board.  Once everyone was sitting comfortably, had cleared their minds and entered a trance-like state the product owner read out the story and the team clarified the acceptance criteria.  Then the story was placed in the middle of the table and each team member put one finger on the story – in silence. Without discussion or argument the story started to move towards the number which reflected its size, by the act of the team members pushing or pulling the story towards their chosen number.

Continue reading this article.

Ask the Coach

By Manoj Vadakkan

Recently I had an opportunity to speak with Alan Atlas, a Certified Scrum Trainer and Certified Scrum Coach who works for Rally Software. In this conversation Alan shares his insight on the state of Agile and Scrum. He also takes a stab at predicting what is to come in the future. This interview also includes some advice both for budding agile consultants and also for organizations that are trying to transform to an agile way of working.

Manoj: Agile has been here for a while; it is everywhere now – small and large organizations, distributed organizations, etc. What’s new in agile? Where is it going?
Alan: One thing I am glad of is that, in a certain sense, there is not a lot that is new. I think we understand it [agile]; I think it works and I really don’t want people messing with it a lot. Ken Schwaber is fond of saying that the whole thing that got us into trouble in the first place was our search for the perfect process. One reason that Scrum is so strong is that it is a process framework, not a process. It gives you all the important stuff and plenty of room to adapt.

It is true that agile does seem to be spreading everywhere. I saw a question in a trainer’s discussion group where someone was asking, "When is it going to be when the only option to do your project is agile? Then you don’t have to say you are doing agile or waterfall, you will just say we are doing a project." I think we will get to a state where that’s [agile] just the way to do things. Students will come out of school knowing agile, and they will know iterative and incremental makes sense; it will be just as logical to them as waterfall  was to us when we came out of school. When I came out of school, I thought, what possible other way there could be to do a project? It [waterfall] was so logical. You start by collecting things [requirements]; you go thru this orderly process; what could possibly go wrong? We discovered what it was – what could go wrong.

Continue reading this article

Five Scrum Short Stories

By Marko Majki

When I was first introduced to Scrum, I thought "What an easy and beautiful way to be efficient!" After years of doing Scrum, I found that it’s not that easy. It was easy to learn. And, as many times before, “easy come, easy go” was true. It was very easy forget easily learned facts of Scrum. I’ll tell you about some of the traps me and my friends experienced during Scrum implementation. Solving these was more or less successful, but if you recognize at least one of them in your environment, which you weren't aware of before, my article was a success. I will tell you five real stories about people who were on the edge of Scrum and how they succeeded in avoiding Scrum traps. My Scrum heroes' names have been changed to protect their identity. Let's begin.

Proxying Product Owner

"Beware of the ScrumMaster who thinks that he can permanently assume the Product Owner role," I would say. I've heard a similar saying before, "A good ScrumMaster can handle two teams and a great one can handle only one." If you try to do the ScrumMaster and Product Owner role at the same time, you're doomed. You won't be able to perform both roles correctly – that’s certain.

One day, Scott was told at the very end of a Sprint that the Product Owner on the project had to move to another project that had stalled. He was told to act as Product Owner proxy for some time. Scott and the team were in a highly dynamic and quickly changing business, and it was a pretty tough period for the team. The first issue Scott was facing was time. The Sprint was one week long, and he did partially succeed in resolving impediments and barely succeeded in preparing acceptable user stories during the first Sprint. The second Sprint was a total disaster. Impediments started to pile up, and Scott didn't succeed in preparing acceptable user stories. The Product Backlog was filled with a few essays, without good, smaller user stories. And Scott was a pretty good problem solver. He would have certainly been a great Product Owner, if he was focused only on this role. Simply, Scott didn't have enough time to do both roles well for the team. Another issue Scott experienced was context switching, but maybe this is the wrong term. A better term is perspective switching. That was very stressful. At one moment Scott was trying to solve impediments and at another trying to figure out which story would return the investment in the best way. How did Scott deal with this? He didn't. He told the stakeholders to delegate a new Product Owner. Even a non-experienced Product Owner is a better solution than a ScrumMaster acting as Product Owner proxy. Luckily, Scott's Product Owner returned and he was able to keep Scrum on the track.

ScrumMaster as a Team lead

Claire had a pretty strong technical background on system administration, networks, and Java software architecture/development. Top management considered this to be a great asset to the team she was supposed to serve as a ScrumMaster. Because top management had a foggy understanding of Scrum, Claire was considered to be a “Team Leader.” Claire was the most experienced programmer in this team, but didn't even have the role of developer. The other team members were really great developers and quick learners, but new to Scrum. They didn't quite understand the nature of her engagement in the project, even though she had tried to be pretty clear about her role. They knew Claire before this project and had respect for her as a developer. I suppose they expected her to deal with technical issues using her remarkable experience. This asset started to become a great burden for the team and for Claire personally. She knew that if she got deep into coding she wouldn't be able to act as a good ScrumMaster. The first Sprint Planning Meeting started, but when technical debt was discussed, everybody looked at her, expecting her valuable opinion. She remembered something that she heard once from a more experienced Scrum Coach. She asked the team to excuse her for some time and to continue the technical discussion without her. They were surprised, but after she left, they did continue. After some time she returned and they barely noticed her. She was satisfied with the result. When the meeting was finished, she asked the team if everything was ok and how they decided to address technical solutions. Everything was fine and the team was satisfied because they handled everything themselves. She suggested that they would feel better if they made decisions on technical stuff, and that they were very good developers. “Of course,” she said, “I'll give suggestions if needed, but I'm not supposed to make decisions. The team has the power to decide. My job is to serve the team and to be sure that the project and work are running smoothly.” Claire made an "impediment list" sticky note on the wall and asked the team to give her tasks whenever they wanted, no matter what issues they might have. Then they really understood her role on the project.

Support Departments Don’t Use Scrum

Robert was a Scrum Coach for a software department that developed in-house projects. They had used Scrum for almost a year, and were doing a great job. When Robert came to the company, the department was pretty messed up, but in a few months everything fell into place and the teams became hyper productive. This was recognized by top management, teams were regularly awarded, and everything was fine. But Robert was a little worried. At first, he was focused on the teams, and wasn't able to see the whole picture. Using Scrum, real issues were surfacing, but he was focused on the issues he had influence over, and the team was solving them. So, when impediments inside the department were minor, other impediments became visible. The first sign of trouble was that the Product Backlog was pretty empty. He talked with Product Owners and discovered that they couldn't get enough information to create acceptable user stories. “Why?” he asked. Simply put, nobody from other departments had the time to define what they needed, and when they needed some functionality, they needed it immediately. From his perspective, communication with other departments was an impediment, but he felt responsible to initiate the solution. Now, because teams were pretty self-organized and doing well, it was time to spread Scrum to the other departments. First he talked to top management about the situation in other departments and presented the idea about introducing Scrum. They hadn’t originally considered it, but were pretty satisfied with the re-organization of the software department, so they agreed. Robert explained that he didn't want to make this transition top-down, but would try with volunteers. He invited heads of each department to a working breakfast and explained Scrum, presenting potential benefits for the department using its principles. He asked them to bring a few team members to the next three meetings about Scrum. They were pretty shocked when he introduced some of the Scrum games, expecting a PowerPoint presentation. “Hey, you didn't even bring your laptop,” they said. “I don't need it,” Robert replied. After playing two games, he conducted a practice retrospective meeting, allowing the teams to reach their own conclusions. Then he helped them to make parallels with real situations that they were dealing with. It was quite refreshing and revealing for most of them. Then, he explained that Scrum was not a silver bullet, but a tool that could help them to understand the impediments and to enable them to work better. He asked them to consider it and to let him know if they would like to try Scrum in their environment. The next day, the chief of the technical support department contacted Robert, claiming that his team was overwhelmed and eager to try Scrum. "Great!" Robert said. "Let's start preparations for our first Sprint."

Disputed Definition of Done

Ulrich was a pretty experienced Scrum Practitioner. He knew that coaching a new team was going to be tough. They were all experienced programmers, but new to Scrum. Initially, coaching was tough, with much resistance and conflicts; a bumpy road that was now almost behind him. Eventually, things were much smoother because he knew the team's velocity and the team knew their velocity, which was much more important. Velocity was regarding to “DONE DONE” user stories. He remembered the issue the team had with this, their definition of done (DoD). As he explained at the very beginning, the team and the Product Owner had to reach an agreement on this. One of the guys came up with a DoD proposition, and the team and the Product Owner were ok with it. One of the items in this list was "unit test coverage of 80%." After the first few stories were "done," he asked the Product Owner to test the items from these stories. With the tool they had, it was easy to see a unit test coverage of 23%. Ulrich asked the Product Owner what he thought about that. He answered that he wasn't satisfied with that the result. "Why?" asked Ulrich. "Because these stories are not done," replied the Product Owner. "Do you need a unit test coverage of 80%?" asked Ulrich. "No, I don't know why they chose these figures, but if the team defined these, I expect them to meet these criteria," answered the Product Owner. And he was right. The Sprint ended the next day, and during the Sprint Retrospective, Ulrich announced that the Sprint had failed, which provoked a very emotional response from the team members. He explained the reason and showed them real figures on test coverage. "But why is this important? We did all the necessary tests. We didn't want to waste time unit testing trivial methods, such as getters and setters, and we didn't want to test something covered in integration testing," screamed the guy who purposed the DoD criteria. "Yes, you are completely right, but you promised something about unit testing and this was not accomplished. Could you tell me how you determined the proposed DoD?" Ulrich asked. "Well, I didn't know what criteria to propose, so I copied some from a Scrum blog, which looked great at this time." "Ok, guys," Ulrich said, "this is my failure as Scrum Coach as well and it's my fault that you didn't understand the meaning and importance of DoD. DoD is different from team to team and project to project. This is not a general standard that should be implemented in all situations. And Scrum is not a standard that can be implemented the same way in all situations. Those are tools, which help you make better software, but you need to involve your intelligence, energy and creativity to make it happen. Ok, let's do the job. Let's create a DoD acceptable to us and our Product Owner. You are experienced developers and you know everything about good programming practices. You've seen one of many possible DoD's. Let’s make new a DoD we can commit to."

Estimations in hours

Marianne was inexperienced, but passionate about Scrum. She started her first Scrum project with the team and was thrilled, anticipating her first ScrumMaster job. The team knew about Scrum and was interested in trying it. Before the first Sprint Planning Meeting, the Scrum team agreed on some conventions and one of them was estimating user stories and tasks in hours. This was the natural choice for the team and Marianne agreed with that. Estimating in user story points was awkward to the team, since they couldn't figure out how to correlate this to some real measurement unit. So they started their Sprint meeting and started estimating. They estimated all user stories and chose ones they could commit to finish until the end of Sprint. Then, the Product Owner stood up and spoke. "Well, guys, you just committed to finish user stories worth 230 hours and you have 400 working hours in your Sprint. Even if we add 30 hours for the meetings during the Sprint, still there's 140 hours in the Sprint you should commit to. Is my math correct?" "Yes, you're right," said the senior developer, "but a working hour cannot be equal to a development hour. We have to have time to think about the story, business process, architecture etc. So, coding functionality is not the only job we're working on. Development is the intellectual process, not an exact, simple operation. We really didn't underestimate, in my opinion, and we didn't want to „steal‟ some time. I just feel that we cannot commit to more than we already did." "Ok guys," continued the Product Owner, "I believe you were honest with the estimations and I think that this is a fine velocity if you meet those commitments with your definition of done. I just can't figure out this difference and it would be difficult for me to explain this to the stakeholders." It was good timing for Marianne to do some facilitation work. "The way I see it," she said, "we have a problem with the measurement unit. The Product Owner is satisfied with the features to be developed in this Sprint, but somehow user stories measured in hours don't provide the real information, correct? Furthermore, this difference in time is causing confusion. If developer hours cannot linearly correlate with real time, why don't we say points, not hours? After a few Sprints, we will be better in our estimations in these points, correct? And there will be no confusion with working hours and time. After a few Sprints, we will know our velocity in these points and will have more experience in estimating work. Stakeholders will get their graphics in these points and will be able to monitor progress daily. What do you think?" The Product Owner was delighted with this idea, knowing that he'd be able to show diagrams to the stakeholders in real time, and the team was relieved from the pressure they felt after Product Owner's speech. Marianne scored her first small victory helping her team to overcome its first impediment and potential conflict. After a few Sprints, they got used to estimations in user story points, so it came naturally to them.

I hope that you enjoyed these real Scrum stories and that you can recognize some of the situations in your everyday Scrum practice. Please comment on them and comment on how you would deal with these situations.

9 Tips for Creating a Good Sprint Backlog

By Luciano Félix

The sprint backlog is a simple list of the tasks that must executed by the team in order to deliver an increment of functional software at the end of that sprint. Sprint backlog creation happens in the second part of the sprint planning meeting with the participation of every team member. Giving some real attention to this process is fundamental to a better understanding by the team about what should be done and to better planning during the sprint. Despite this, many teams still struggle with this activity. I hope these tips will help.

1. Involve every team member in the process. It can’t be said enough: the involvement of every team member in the process of sprint backlog discovery is essential. On a multi-disciplinary team, everyone can contribute to task creation, enabling the team to draw from several different perspectives about the story. This generates a much richer Sprint Backlog than if only coders or a technical guru were involved.
2. Discuss how every item should be implemented. Before any tasks are written on post-its it's necessary for the team to spend some time discussing every story that will be brought into the sprint. In fact, the majority of the meeting should be dedicated to understanding how the team is going to tackle the stories. This discussion will involve creating basic designs, checking existing code, discussing architectural possibilities, and so on. Having a shared understanding about the story and the possible solutions will enable the team to create a task list that truly expresses the work to be done.
3. Have a definition of done. Having a common definition of done in place, available and visible to everyone is extremely important. This definition will serve as a guide to what should be done and will remind the team what the general acceptance criteria are for every item in the backlog.
4. Identify all kinds of tasks. Too many teams focus on coding tasks. The truth is, though, that coding is not enough to deliver real working software. The sprint backlog should include every kind of task: object modeling, coding, learning a new technology, database activities, tests, and so on. Having a posted definition of done will help to remind teams of the tasks they are forgetting. By listing every aspect of delivering working software and going through those tasks, the team will gain a new understanding of the real effort the next sprint will require.
5. Don't estimate tasks at all. This is a sensitive one. Estimating tasks in hours is popular and may be necessary when a team if first starting out. In the end, though, we can drop this without losing much. (See Alan Atlas’ article about this topic) The team commitment to the sprint should be done with the backlog items in mind, not the tasks. After all, if we estimate that a task will take 4 hours but it actually takes 12 hours, as long as the team achieves the sprint goal, what difference does it make? Identifying as many tasks as possible and creating a sense of constant progress during the sprint should be enough.
6. Don't assign tasks up front. Resist the temptation to direct work; the team should decide who is going to do what according to the circumstances. If you start to assign tasks to the “most suitable” team member, it will prevent the rest of the team from learning new things, block communication, and decrease collaboration. Empower and trust the team to manage themselves.
7. Review the sprint commitment. After task identification, when the team has a much better understanding about the real effort that is needed, the sprint commitment should be reanalyzed. Does the selected sprint backlog really fit in the sprint? If not, there are some alternatives. Drop the item with the lowest priority or split stories into smaller pieces. What matters in the end is that the team can commit to something they have a good understanding about.
8. Don't use too much time. Respect the time box. Define a meeting duration and stick to it. Timeboxing forces the team to concentrate and intensively discuss the items, making it much more likely that the tasks will be uncovered. The team cannot always identify everything that should be done during the sprint, but that's not a problem. It is much more important for them to gain a thorough understanding of the stories they are bringing into the sprint.
9. Evolve the Sprint Backlog during the sprint. The team will understand more about the stories as they work on them. New ideas may arise and old ideas may be dropped. The Sprint Backlog should reflect these changes. The Daily Scrum is an excellent time to create new tasks and lose unnecessary ones.

If the team invests the time and effort to build a good sprint backlog it will be rewarded with a much better overall understanding of the work to be done, a sense of progress on a daily basis, and a clear commitment to what will be delivered. It may not be easy, but it will be worth all the hard work.

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.

A Cure for Task Estimation Obsession

By Alan Atlas

I often see teams obsess over sprint planning, especially the task estimates. I mean really obsess. Two days of planning for a two-week sprint? Believe it or not, it happens. Even as they complain about spending too much time in scrum meetings, they will insist on arm-wrestling over each and every task estimate. For teams that want to take advantage of their scrum experience and streamline their planning, eliminating task estimates can be an option.

Don’t look so shocked. It is possible. One big caveat, though. For those teams that are new to Scrum, I do not recommend eliminating task estimates until you have established a stable velocity.

Once you have a stable velocity, however, you can use the concepts of story points and velocity to eliminate the need for task estimates in sprint planning. The time you used to spend estimating tasks can then be used more wisely to create working software. I will present a series of steps you can take to gradually eliminate task estimation from your sprint planning process.

Background

Before we get started, let’s quickly recall the reasons why we do the sprint planning things that we do. (We’ll want to make sure we can still meet those needs when we’re done streamlining the process.) We plan the sprint in order to create the following:

1. A shared understanding across the team of the goals of the sprint;
2. A shared understanding of the work that needs to be done during the sprint;
3. An environment in which team members know what to do next (or can find out in seconds);
4. An achievable team commitment to deliver a certain amount of value, expressed as product backlog items; and,
5. A burndown chart that we can use to track our progress through the sprint.

Task estimates most often contribute to goal five above, and for some teams, to goal four. If we can achieve those two items without creating task estimates, then we are free to choose not to use task estimates at all, aren’t we? If you agree, here’s a way to transition away from doing task estimates as part of your sprint planning.

Step 1. Establish Stable Velocity

Use your normal sprint planning process, whether it takes two days or two hours, for each sprint until you can demonstrate stable velocity. (There are many discussions of how to achieve stable velocity out there; it is too large a subject to treat here. For more on agile estimation, I recommend Mike Cohn’s Agile Estimating and Planning.) Make sure your team passes the Nokia test by producing potentially shippable software each sprint (in other words, you’ve proven that you can calculate your velocity correctly). When you have achieved stable velocity, your team will be able to make, and meet, sprint commitments based solely on demonstrated velocity and story point estimates of Product Backlog items. You want to do this anyway as part of having a good scrum implementation, right?

Step 2: Experiment with a Task-Based Burndown

When you think you’re ready to stop estimating tasks, start to use two burndown charts instead of one. Continue to use your normal work-based burndown, which is based on the task estimates from the sprint backlog. Add to it a new burndown chart, which will be based only on the number of tasks in the sprint backlog, regardless of their estimates. The new burndown chart can be called a task-based burndown chart.

Your familiar work-based burndown chart starts with the total of all task estimates for the sprint and, as estimates are updated daily, the burndown continues to reflect the estimated amount of work left in the sprint.  Hopefully it will usually trend down toward zero. Your new, task-based, burndown chart starts instead with the total number of tasks listed for the sprint. Estimates aren’t updated for this chart, and work is burned down when a task is completed (its value on the burndown goes from 1 to 0).  For best results, make sure your task breakdown results in the smallest tasks possible. The task-based burndown chart reflects the estimated total number of tasks left to do in the sprint and not the estimated work effort left. This works best if you have lots of small tasks, typically ones that can be done in a day or less.

Make sure that both burndowns agree and that both give you the same visibility into your progress during the sprint. If you find that the task-based burndown isn’t useful, take a look at Step 3.

Step 3: Shrink Tasks to Improve the Task-Based Burndown

A good, informative task-based burndown chart depends on there being many small tasks to burn down. Conceptually, if you only had one task per PBI on a sprint backlog, you could have a perfectly good work-based burndown chart because the daily updates of the task estimates are given with arbitrary granularity (Now, if your PBIs really have only one task each, it’s indicative that there is a problem with either your stories or your task decomposition). In contrast, the task-based burndown chart for this sprint would be very insensitive on a daily basis, because the tasks would tend to span many days, and progress would not show until a task was completed. The remedy is to make tasks small. A good rule of thumb is that a task should be something that can be completed in a day or less.

Step 4: Stop Doing Task Estimates

When your two burndown charts convey similar information and when you can deliver on velocity-based sprint commitments, you can stop doing task estimates and do away with the work-based burndown. For some teams this will be easy to achieve and for others it could take many sprints. The key to this is to use the idea of velocity correctly. Note that you will still want to be doing the task breakdowns for now. Eliminating them is a different step altogether.

What did we lose when we did away with the task estimates? Task estimates support planning needs four and five from the list above. We still have a burndown chart that we can use to track progress, so we still support goal five.  We have removed the need to support goal four because our team has demonstrated the ability to make commitments based on story point estimates of PBIs and does not need task estimates for validation.

The only thing we might have lost is tangential support for planning need number two. That is, by not asking for estimates, we may have removed some of the mental pressure and motivation to think deeply, look for issues, recall similar efforts, and in general actively bring knowledge and experience to bear on the problem of correctly planning out the tasks. How big a deal is that? The answer to that question is unique to you and your team.