The Team is doing a planning meeting. The Product Owner brought along some documents, specification and printed e-mails, and The Team tries to understand what they mean. After they have organized it into a prioritized backlog, they want to size the items to find out how many of them they can take into the sprint. But then the Product Owner tells The Team they really have to do all of them. After all, the product is due next month, and testing is already behind schedule…
I like to cook. I enjoy the chopping, mincing, frying, boiling and stirring that changes raw ingredients into something better. And I like the reward of a good meal, preferably together with family and friends.
When I prepare an everyday dish, I just start chopping an onion, throw it in the pan, add some vegetables and seasoning, and then cook the pasta in the boiling water that I didn’t forget to put on the stove first. It is a rather organic and messy process, which nevertheless results in a tasty dish, usually. I know the things to do and the order in which to do them well enough that I can just start.
When I prepare something more complicated, or a dish I have never made before, the process is different. First of all, I carefully read the recipe, to know what is expected of me. Then I actually chop the onions, slice the vegetables, and put the different ingredients on the table, so I don’t have to search for them while something else is burning; only then I put the pans on the fire and start cooking.
The preparation makes the cooking easier; whenever there is something needed right now, it is available right now; I don’t have to add an ingredient that I need to chop first, or find in a cupboard, or buy because I don’t have it. Chances for success are much higher when I make a plan.
When writing software, often a new feature is a dish you have never made before. So just like when cooking, success depends on careful preparation.
They say that planning is half the work, and that means a good sprint planning session can save you a lot of time. Good planning works two ways: the team knows exactly what to do, and the stakeholders know exactly what you are doing. Those two ways help each other. If the team knows what to do, they deliver lots of working software; if the stakeholders know what is in the works and when it is due, they are more likely to leave the team working on it and not interfere.
Effective sprint planning consists of three components: accurate sizing, careful tasking and full commitment. If you get those three right, you can work effectively and undisturbed for a full sprint afterwards.
But it is still not easy to get it right. How do you size well? How do you get the most out of tasking? And how can the team confidently commit to the sprint backlog?
Planning the Planning
“Ladies and gentlemen, this is the planning meeting, isn’t it? So this sprint you need to do the web interface; the specifications will come tomorrow, and the design is created as we speak. You can keep yourselves busy in the mean time, I trust. You’ve seen the web site’s mock-up in my presentation, haven’t you? Is there anything else you need? So, let’s go!”
If planning is half the work, than preparing the planning is vital. For the team to be able to do an effective planning session, you must prepare well. Not only the session must be prepared, but enough of the product backlog must be in good shape as well, or else there is no work to do.
Preparing the Session
For a good sprint planning, the team must be able to work uninterrupted for a couple of hours. So make sure you have a dedicated room or area, with no distractions.
What do you need to bring to a planning session?
- The user stories, written or printed on cards, large enough that you can read them from a distance.
- Spare paper, to write new stories if necessary.
- Stickies, pens, markers.
- A whiteboard might come in handy.
- Any information that might help in understanding the stories, for reference.
- Lots of coffee, tea or other refreshments.
One more thing: the team should know the velocity from the previous sprint(s). If they don’t know it by heart, or it is not very well established yet, bring historical data about the previous sprints’ velocity.
User stories are descriptions of new features in one or two sentences of plain language. Even if your organization uses a different way of specifying requirements, it’s a good idea to write user stories for use on the Scrum board. They are an easy to remember, short description of the work to be done.
Often, user stories are written like this:
As a system administrator, I want an easy way to deploy the server application so that I make less mistakes.
As a word processor user, I want errors in my Latin grammar be highlighted so that I am able to find and fix mistakes as early as possible.
Although this format is sometimes awkward, it describes features from the viewpoint of a user of your software, and explicitly states the benefit for this user. There are two reasons for doing this. You will remember why you are implementing a feature; that will help you make decisions about design or implementation. For example, the system administrator above wants to make less mistakes, so “easy” really means “less error prone”.
Also, sometimes you find a different way to get the same benefit to the user (e.g. instead of highlighting errors, fixing the Latin grammar mistakes right away!) If your feature description just reads “Highlight grammar errors” you might miss this opportunity.
Correctly written user stories describe tangible, finished features that can be demonstrated easily. It helps to stick to the form:
As a <somebody>, I want <something>, so that I <benefit>.
Usually, if it is hard to put in this format, it is hard to demo as well. Take the following example:
As a user, I want an expert system of Latin grammar rules to be stored in a database.
“As a user” was just put in front here to adhere to the format. As a user I don’t care what an expert system is, let alone where it is stored. As a user, I want to write correct Latin. This last user story is not complete (it describes no benefit to the user) and describes an implementation, not a feature.
It will show when you try to demo this feature. Highlighted grammar errors are much easier to demonstrate than database contents.
Ready (or READY)
Before you can do a planning, the backlog must be ready. And that means that there are enough stories to keep the team busy for a sprint, every story is well enough understood that they can start working on it, and that the priority order of the stories is clear. The Product Owner is responsible for getting the backlog ready. He or she usually doesn’t do this all alone, but the Product Owner has to make sure it is done when the sprint begins.
During the sprint planning, the Product Owner should be present to re-prioritize stories, take them out of the backlog, or change them, if there is a need for that. For example, if a story turns out to be much more difficult than the Product Owner expected, he or she can reconsider whether it needs to be done at all. Or if a feature is not necessary as the team explains there is already another way to do it, the story may change (“improve the documentation” instead of “implement new feature”.) Of course, if the backlog is really ready, this will not happen very often.
The team should never start working on stories that are not really ready. If requirements are unclear, or for example translations are not available, or there or no machines to install on, the team cannot work on that story. They should give it back to the Product Owner and advice to postpone it to the next sprint.
The Team is doing a Planning meeting.
“Well, the last four stories on the sprint backlog were not really finished, so we continue working on them. Then I guess I should also do this one, and of course Giulio does the database story. So…”
“Guys! Guys!”, the Product Owner said.
“Do you have any idea when this will be finished? Do you have any idea when anything on the product backlog will be finished?”
Although sizing is a bit of a black art, it is an important planning tool. Not only is it necessary for the team to take the guesswork out of the sprint planning; in the longer term, the stakeholders need it to make a release planning.
Planning in Scrum revolves around one concept: velocity. But that is all you need to plan the future.
Establish the Team’s Velocity
The purpose of a planning meeting is to come up with a sprint backlog: exactly enough work to keep the team busy for one sprint. How do you know what is enough work? The key to that is the team’s velocity. The velocity of the team is the amount of work they can do per sprint.
For this, you need to establish a size for each of your stories, because not every stories has the same complexity or will take the same time to implement. The sizes don’t have to be absolute, though: you don’t have to estimate the duration of the stories’ implementation in hours or days.
Doing that is hard, anyway. Most human beings are overly optimistic. They forget the time it takes to set up their systems, remember what they were doing yesterday, drink coffee, and numerous other things you do besides the actual work. But that is not really a problem because the error made is more or less systematic: estimates are a factor off, but always the same factor off.
Using velocity solves this by actually measuring how long it takes to do the work after you have sized it, thus establishing that factor. Instead of guessing how much you’re off and compensating for it, you just measure how much you’re off and use that factor on your future sizes.
So for your first sprint, you estimate the size of a number of stories on the top of your product backlog, and take in to the sprint as much as you think you can handle. For the next sprint, you know how much you did in the previous sprint, and use that number to guide you. Over time, your velocity will become clearer, as you can look at the average velocity (and the trend) over the past few sprints.
Use Story Points Instead of Ideal Days
When you use velocity to measure how much work you can do, you don’t need to estimate in person-days or person-hours anymore; they don’t directly match with real days or hours anyway. Instead, you can start using story points.
A story point is a unit of measure that is made up by the team itself. You just take a medium-sized story and assign it a size, and then you size all other stories in comparison to that one. A story point thus has only meaning within the team; another team may have completely different story points.
At first sight, story points might look less precise than person-days, but they are not. It is actually less precise to multiply person-days with a factor (to account for the fact that they are not real days) than to work with velocity and story points in a fixed-sized sprint. But if you size in ideal days, you are suggesting to the stakeholders (and maybe even yourselves) that you talk about real time. The arbitrary story points don’t suggest that.
Using story points also invites the team not to think in too much detail. Instead of trying to imagine all the days of work you need to do on a story, you compare it to similar stories. That is easier to do and you’re less likely to miss chunks of work. Also, it is less determined individually. An expert in the field might estimate many days less than a novice, even though they might consider the size the same.
If you know the team’s velocity, and you have sized backlog items in advance for a couple of sprints, you can very easily derive a release plan from it. If you put the backlog in priority order, you can chop it into sprint-sized chunks. And then, for every story in the backlog, you can see at what date it is likely to be finished, as sprints have a fixed length. From this plan you can determine when a release can be made and what will be in it. Of course you have to account for some uncertainty, as velocity is an average number.
If your sprint history is long enough, you can derive the worst case velocity and best case velocity by taking the average of the slowest sprints and the fastest. Using those two velocities you can derive the earliest and latest release date based on actual team performance. As more work gets done and the time to the release becomes shorter, this release interval will shrink, until it is contained in one sprint. You can make a graph that will show this interval clearly.
The nice thing about such a release plan is that you can change it anytime by re-ordering the backlog, without disrupting the team. Product Owners can align the backlogs of several teams to make product- or program-release plans far into the future, but the plan is never fixed for more than the current sprint. This is a flexible way of roadmap planning that fits in very well with agile development.
What’s the Use of Velocity for the Team?
For the team, it is important to know their velocity as well. First of all, the team can use it to know how many stories they can take in. This will add some confidence to the planning.
Another reason to keep an eye on your velocity is to see it improve. If impediments are cleared, the team is working together for longer, and the knowledge and collaboration between team members increases, you velocity will go up. This is of course a good thing: the team becomes more productive.
On the contrary, your velocity can also go down. That needs some investigation. Why did it go down? Is it just because team members were on holiday or did you do less work per available man day? Are there external circumstances that explain it? This could be a good starting point for discussion in the retrospective meeting.
Size before the Planning Meeting
The product backlog is truly “ready” if enough items in it are sized before the sprint planning. That way, the team knows exactly how many stories they can take into the next sprint; they just peel stories off the top of the prioritized product backlog until the total equals their velocity for the next sprint (or a bit less, or a bit more). The product owner can then choose to change the order a little to cram in more short stories, or take out short stories in favor of a long one.
In reality, you usually have to do a bit more in the planning meeting. Some stories might still be unfinished, and need to be looked at again. Some new stories might have been created recently, and need to be done in this sprint. But it is good to make sure your product backlog is always as ready as possible.
If all sizing is done in the sprint planning meeting, it will take a large part of the time. Probably some team members see the stories for the first time, and need to get their head around it. But after that, the Product Owner probably will have to re-order, and run around and talk to people, and tell lots of people bad news, because the actual contents of the sprint comes more or less as a surprise. In the mean time, the team is waiting.
If the sizing is done well ahead, only the last few stories are uncertain, but even that is known in advance. That means the Product Owner can decide on the spot what goes in and what not.
It is of course possible to size stories for the next sprint in the sprint planning meeting. But it is better to have separate sizing meetings, or to size one or two items every day. You could for example do that right after the stand-up meeting, when the whole team and the product owner are present anyway.
What Sizes Are Not
“So, how many story points can your team do?”
“Well, last sprint we did 12.”
“And what’s the size of that story? Eight? I’ll give it to Robert’s team then. They do 40 story points each sprint.”
Story points are a unit of measure made up by each team individually. That is why the conversation above doesn’t make sense. But comparing teams can be very tempting. Resist the temptation; it can’t be done.
Velocity Is Different for Each Team
You cannot compare velocity between teams. Each team has their own strengths and weaknesses, so if a story is passed on to another team, the team needs to size the story again. If you size stories in ideal days you might be tempted to go with another team’s size, but you shouldn’t. The other team might have different expertise and a different approach to the story. But also, sizing a story with the team means the team will understand the story, so it will not be a complete surprise when it comes into the sprint. When you are using story points instead of ideal days, it will be more obvious you have to size the stories again, since another team’s story points are meaningless to you.
The focus factor of the team shows how much the team can do per man day. The easiest way to explain this is by an example.
Assume team A can do 20 story points in a three week sprint (their velocity is 20). The team consists of 5 people, so the availability (in working days) of the team is 5 people × 5 days × 3 weeks = 75 days. This means they do 20 ÷ 75 or 0.27 story points per available man day. This number (0.27) is called the focus factor.
The focus factor is a useful number for the team to compare sprints, because it factors out the number of man days. Assume their are some holidays in the next sprint, or some people not present, you can multiply the number of man days with the focus factor to get a reduced velocity for that sprint. Don’t overuse it, though; if half of the team is gone, including your database specialist and your only tester, don’t assume your velocity is going to be half that of last time. It will be much less.
Universal Velocity Is a Myth
It might be tempting to come up with the concept of universal story points that allow you to compare teams. And actually, it is pretty easy to do. But if you do the math, you’ll see it’s a rather useless exercise.
Let’s look again at team A that has a velocity of 20 and a focus factor of 0.27. Now take team B. Their velocity is 50, but this team consists of only 4 people, and one of them is a part-timer. Why is their velocity so high? Not because they are much better, but their story points are much smaller.
Remember how we started using story points? Take a medium-sized story and assign a size to it, then size all other stories in comparison to that one. Here team A took a medium sized story and gave it a 3, but team B took a story of roughly the same size and assigned it size 13. Neither of them are wrong; Team A will probably not use numbers above 8 a lot; team B will not have a lot of stories of size 1. But the relative sizes of all their stories can be equal.
Another way to explain the difference is to look at the focus factor of both teams. Team B’s availability is 3 people × 15 days, + 1 × 9 days, makes 54, so their focus factor is 50 ÷ 54 or 0.93, more than three times as high as that of team A.
But if you look at the average amount of work each team member has done per day, we can say that the 0.27 units of work done in team A equals the 0.93 units of work in team B, if everyone is working equally hard. To equalize velocity, we can both set them to 1 and adjust the story points accordingly.
Now the velocity of team A = 20 ÷ 0.27 = 75 and that of team B is 50 ÷ 0.93 = 54. Surprise: the velocity of both teams is equal to their availability. If you think about it it makes total sense. If each team is working equally hard, then their productivity is always going to be equal to their availability.
So if you wanted to compare the performance of teams by comparing their velocity, think again. You’re only comparing availability, and there are easier ways to that. The only velocity you can compare to is your own velocity in the past.
Sizing Is Not Easy
That was a painful planning meeting. The product backlog was huge, and the Product Owner seemed determined to cram in as much as possible. “We have to finish on time, else we cannot ship before Christmas.”
To make matters worse, the CTO attended the meeting and helped sizing. And even though The Team objected and argued and haggled, he had the final word on some stories that really “shouldn’t be that difficult.”
Now the sprint began. Soon The Team realized it was not going to be hard to prove the CTO wrong…
If your sizes are wrong, your planning is not worth much. Your sizing needs to be as accurate as possible. But also the whole team must believe in them, because you cannot commit to a sprint backlog if you think it can’t be done.
Size With the Whole Team
How do you size stories? One thing is really important: size them with the whole team. Even if there are specialists in the team that are much better at doowopping or fiddlydiddling than others, you shouldn’t let them do the sizing and ignore the other team members. There are a number of reasons for this.
If the expert sizes, the expert must do the work, or the size is not accurate. That is not a good thing in a team. It prevents working together and makes the team feel less responsible for the work.
If the expert is ill, he cannot do the work. If the team collaborated in sizing the story, they know at least what it is about, and someone might be able to take over.
One person might misunderstand the story. If the whole team participates in the sizing, and they heavily disagree about the size, maybe some members don’t really understand the story. Then the Product Owner can explain the story better.
Planning Poker® is a fun way to size stories that makes collaborating on sizing very easy. Using cards, each team member votes for a size, by showing a size at the count of three. If the sizes vary a lot, the high and low voters explain their size. Then you repeat voting (and discussing) until everyone agrees. Don’t take the average without discussing; the whole team should participate and the whole team should agree. Don’t let the discussion go on endlessly, either; settle for a number if everyone can live with it.
The cards you have for voting are usually marked with Fibonacci numbers: 1, 2, 3, 5, 8, 13 and 21. The reason for the missing intermediates is that you don’t get too much false precision that way. It is impossible to size as precisely as “this is 15, not 14”. It is much better to be forced to choose between 8 and 13 or 13 and 21.
There is a lot of information about Planning Poker® available on the internet. You can also buy professional, durable poker cards on-line.
Re-size Unfinished Work
Sometimes a story from the previous sprint is not finished. Although it is very tempting to count part of its size into the sprint’s velocity, it is better not to do that. After all, the story is not finished. It’s hard to tell how much is, and not counting it at all will be an extra incentive to finish all stories in the next sprint.
Another thing that might appeal is to take the full 13 story points story into the next sprint and finish it within a day. Now that will look good on your burn-down chart! Again, it’s better not to do that. Although the average velocity over several sprints will be more accurate this way, the actual value will jump up and down very much. This will make it more difficult for the team to decide what is a good amount of story points in a sprint, and might cause some unnecessary discussion and worries in the retrospective meeting.
The best way is to re-size the remainder of the story. Then the size of the story as it gets into the sprint matches the work that needs to be done; it will make your velocity more stable. Also, it will make the release plan more dependable: all work that still needs to be done is accounted for. And if the team gets better at finishing all stories, you will actually see your velocity improve, because no half-finished stories disappear between sprints.
Break It Down!
“Jeff, what did you do yesterday?”
“I’m still working on that story.”
“And what will you do today?”
“I will continue working on it.”
“Can anybody help you, maybe?”
“I don’t know…”
If a story is a mystery to all team members except one, working together is hard. Part of planning your sprint therefore is breaking down the stories into tasks. Breaking down a story is useful for a lot of reasons:
- As a team, you will fill in the details of the story, learning what needs to be done to implement it.
- You can verify whether the size of the story still makes sense.
- As a team, you get on the same page what’s in the story and what is not.
- If the tasks are independent enough, people can work on the tasks in parallel.
Task Your Stories
For each story, the team decides what tasks need to be done to implement it. Tasks should be relatively small (not more than one or two man-days) and written out clearly. Try to make tasks independent, so that people can work on them in parallel. Write the tasks on yellow stickies and stick them to the story. If anything about a story is still unclear, it will become apparent during the tasking. The Product Owner should be available to explain it again.
Use your tasks also as reminders for edge cases that need to be checked, e-mails that need to be sent, or questions that need to be asked. Be as clear and complete as possible. You might start working on this story only in two weeks time, so don’t assume you will remember everything by that time.
When tasking, you are actually drafting the technical design for your implementation. It is important to do it carefully. If a story is not tasked very well, the team members that will work on it will get stuck. Investing some time now will save you a lot of time later.
Tasking is very demanding and time consuming. Make sure the team is prepared for that. Take breaks, and make sure you don’t rush it.
If you want to, you can make a time estimate for each task. The estimate for a task should be somewhere between half a day and three days; else your tasks are too small or too large. Although it means more work, estimating tasks has some advantages.
First of all, it will give you some idea what can be done when. If a task depends on another task, it is useful to know when that first task can be done. Estimating your tasks gives you the information to make a rough plan for the coming sprint.
Furthermore, you can track the duration of tasks during the sprint. If a task was estimated to take half a day but is on the “In Progress” column for two days, something is wrong. This can be a sign of an impediment, or an early warning that a story was under-estimated by the team. But maybe the person working on the task abandoned it and is working on something else. In any case, if you notice this, you can do something about it.
The added time of all tasks is also a sanity check of your story’s size. If a story sized at 8 story points has 10 days of tasks on it, a 5-point story should have about 6 days. If it has only 2, you should consider resizing the story or rethink your tasks. If it has 7, it is probably OK.
You don’t have to estimate tasks. If your tasks are small and well understood by the whole team, it might not be necessary to stick a time estimate to them. If tasks have very different sizes, though, it is probably worth doing it. A big task that is a mystery to some team members can add a lot of uncertainty to your sprint.
At the end of the planning meeting, the team should explicitly commit to the sprint backlog. They should, as a team, agree to do all the work in the coming sprint. If anyone in the team has any doubts, discuss it. Should you take in less stories? Should you take out that story until that investigation has been done? Should you postpone that story until Janet is back from holiday? Together with the Product Owner, the team should arrive at a sprint backlog they really feel they can complete.
Note that you can commit to a backlog without tasking it; tasking can be done during the sprint. There is a risk involved: sometimes you don’t realize until tasking that you under-estimated a story wildly. In the sprint planning, you can immediately adjust the sprint backlog with the Product Owner. If you find out halfway through the sprint, it will be an unpleasant surprise to your stakeholders. But if the team is experienced and knows the backlog well, they can consider committing without tasking. And if you manage to finish the sprint, you know you have arrived.
If the team committed to the work, they will probably finish it; and if they finish the work they promised, they will make their stakeholders happy. In the end, that is going to help the team a lot as well. Happy stakeholders are much less likely to interrupt; they are more likely to wait with new work to the next sprint, especially if you tell them that that is exactly the secret of delivering on time.
Planning: Getting It Right
The Team was doing a planning meeting. After re-sizing the remaining story from the last sprint, they briefly discussed the top stories on the product backlog and decided to take the top five into the next sprint. Then Charlie noted that they could take in the seventh story as well, because it was only two story points.
The Scrum Master asked whether The Team could commit to this sprint backlog, and they all agreed it was doable.
The Scrum Master knew that the Product Owner was under pressure from the stakeholders to deliver by September. He asked: “Gary, as a Product Owner, can you live with that?”
“Of course. I’ll see if we can postpone the beta by one sprint, but if not, we can probably take out the auto-complete feature and still finish on time.”
Any business relies on good release planning. In Scrum, a good release planning depends on accurate sizing, careful planning and a good execution of that planning.
Take your time to get the planning right. If the planning is sloppy, the sprint is not going to be any better. You will change plans frequently, disturbing your own sprint, and creating stress and uncertainty for the team and the stakeholders. And in the end, your velocity will be uncertain, making release planning impossible.
But planning is not that difficult if you cut it in small pieces. Write clear stories and make sure you understand them well:
- Have them rigorously ordered by business value.
- Size them carefully with the whole team.
- Take your time for tasking.
- Then, take in as much as (and not more than) you can handle in the sprint.
That’s all. Now the team can work in peace. And in the long run, the product owner and your stakeholders will be grateful for your strict planning: they will know exactly what you can deliver, at any time.