I was recently asked whether it would be OK for a team to complete their iteration planning without going to the point of estimating tasks in hours. To answer this, let’s consider what the purpose of iteration planning is.
In my view, the purpose of the iteration planning is for the team to arrive at a commitment to some set of functionality that they feel reasonably confident they can complete in the coming iteration. The purpose is not to identify tasks. The purpose is not to estimate the number of hours for each of those tasks. The purpose is to figure out how many and which product backlog items they can commit to delivering in the coming iteration.
If a team can do this without discussing tasks and hours, so be it. If a team can walk into the iteration planning meeting and one team member announces, “Sssh, I’ve receiving divine inspiration……… We can do the first three items plus the sixth on the product backlog,” I would call the meeting over and we’d have our commitment. I’d be impressed and I’d be skeptical, but we’d be done with the meeting.
Since I haven’t seen a team do this yet, I strongly recommend that an iteration planning meeting involve identifying tasks, estimating the effort of each, and then using that information to arrive at a set of product backlog items the team can commit to. I think this is the best way for a team to arrive at that reasonable commitment that I believe is the purpose of this meeting. Is it the only way? No. I’ve also worked with teams who decide that they will split work up such that all tasks are “about half a day”. They then can skip explicitly estimating the hours for each task because, in a way they’ve already done it.
But, until I learn how to receive divine inspiration at the start of my iteration planning meetings, I’m sticking with identifying tasks as hours as a good way to figure out how much to commit to.
Tags: agile estimation, product backlog, sprint backlog, sprint planning
Why estimating tasks in hours? I like this post and I’m glad to get confirmation on my own feelings about the Iteration Planning – and the usual pragmatic attitude of things in agile development. …But I’ve never understood why tasks need to be estimated in the unit of “hours”.
We estimate in days, smallest estimate being 0d or 0.5d or so (although it’s of course more of a guideline than a rule).
Doesn’t estimating in hours give a false sense of security? Rather roughly right than precisely wrong, right?
Thanks for an excellent blog that I follow closely.
I think that tasks that are bigger than a couple of hours tends to be too big. And from a management point of view it is important to be able to see the costs for an individual story. If a story tends to become too big when it comes to actual implementation, you might not want to do it right there and then. And it’s very easy to miss stuff if you just pack the tasks in large hunks of work. The actual division of tasks gets the more junior developers to understand what is to be done. You don’t miss so much stuff. Compare with home shores: if there is only a task which says ‘clean bathroom’ you don’t know if it’s cleaning under the tub or just remove the worst mess. So depending on who is doing the stuff, different things will be done. Then you might say that you can see that from the estimate but really, different people focus on different things.
If the tasks are smaller, there are more easily distributed between team members which lessens the risks for people sitting and waiting for others. And it’s also easier to track the progress on the sprint if you have a sprint burndown. Also, it is also easier to cut things during the actual sprint: it is easier to cut out small tasks that have already been defined.
If someone becomes sick or works part time, it is easier to see where the team is if the tasks are smaller: there are not only these big blobs going on.
And yes, this is an excellent blog! If you haven’t read Agile planning and estimating you have something to read during the winter holidays.
A side-effect of the task breakdown – whether you do it in hours, half-days or whatever – is that the whole team have had a level of discussion about what’s involved. Even if (as I usually do) I get pairs to work on the task discussion, others will cross-check. The other point to make is that the teams own the tasks – if they want or need to change them during the sprint, they’re perfectly free to do so: it’s important to understand this, otherwise the task breakdown starts to look like a plan…
Well, God does work in mysterious ways…
Thanks Mike. I appreciate the great feedback.
Hi Richard–
Most teams find that estimating in days leaves the tasks to being too large. As two-week iterations have become the most common, this is especially true. If a team estimates in days they tend to estimate with 1/2, 1, 2, 3, and 5. (Of course other numbers get used but these are where estimates tend to cluster and this is understandable.) When a team estimates in hours I find they use 2, 4, 8, and 16.
So choosing between is a preference between larger tasks and more-precise-looking estimates.
Better to be roughly right than precisely wrong: absolutely, but a team can still do that by rounding up most hour estimates and avoiding discussions of “is this 14 or 15 hours?”
Hi Anna–
That’s an excellent description of why teams seem to prefer smaller tasks. Beyond what you’ve listed one that comes to my mind is that smaller tasks and smaller user stories flow through the process more smoothly. This is one of the goals of a lean approach (which is quite similar to agile).
Thanks for your kind words about this blog and the Agile Estimating and Planning book. A funny and timely anecdote about that book: Two years ago Amazon put “Want it for Christmas?” icons next to just about every item on their site. Hopefully they filtered out menorahs, Festivus poles and such. But they had a “want it for Christmas” icon next to my books. All I could think of was the disappointed look on someone’s face when they opened up the AEP book for Christmas instead of some great DVD or page-turner novel.
Hi David–
You are absolutely right that the discussion is a big part of the benefit of doing iteration planning. While I’m not on a quest to rename this meeting, when I teach classes or coach teams I stress that the iteration planning is equal parts planning meeting, technical design meeting and product design meeting. I started to go into that subject in this blog post but decided to save it for another separate post, but it sounds like you know what I mean already.
Mike, I agree with what you’ve posted, but I’ve got a slightly different view to posit, based on working in a dysfunctional Agile environment for the past 2 years. I’d very much appreciate hearing what you have to say about my observations.
Our teams were using Story Points to estimate backlog features and typically had 2-week Iterations. Our Product Owners often under-specified what they were asking for on behalf of our (remote) customers, and were sometimes not even available to the teams during planning. Repeated attempts by me, as the company’s Agile Manager, to fix this situation came to naught, and in the meantime the show had to go on. So imagine a setup like that as I get to my point…
After more than a year of operating that way, and seeing many teams “fail” their Iterations because so many of their estimates turned out to be “wrong” once the process of discovery played out over the course of the Iteration, I had a revelation: what if, instead of spending many hours each Iteration trying to plan out every task that they thought was required and attaching a time estimate to it, the teams simply worked on the backlog items in priority order and delivered as much as they possibly could? They would still do some task breakdowns so that everyone understood what they were planning to do, but they’d worry a little less about delivering exactly what they’d come up with. Part of my reasoning stemmed from the fact that Iteration planning sessions were getting longer and longer as teams built up more and more process around trying to anticipate all of the things that could go wrong to impact their ability to hit 100% of their deliverables. They would start accounting time for changes in direction, meetings to get clarification, distractions of all sorts, and so on. Sometimes planning for 2 weeks would occupy an entire day, because of all that!
Now, clearly this was a bad environment and not what you’d want, but it was what it was. To my way of thinking, it didn’t make sense to hold the development teams accountable for their end of the bargain (committing to a certain set of features before building them) when the other part of the arrangement wasn’t being honoured. Therefore I thought that the most expedient approach was to simply focus the teams on throughput, rather than predictability.
So just how bad of a man was I, really?
And have you ever encountered a situation like that in your travels?
What I would find more interesting question to answer is: what prompted the person to ask that the estimation part be dropped?
Such an insight could prodice all kinds of information about how the processes is travelling with in the company and what, if any changes need to be made.
Matt–
What you are describing is essentially what is coming to be known as “Kanban Development.” David Anderson runs a Yahoo group for discussions of it. The idea is that establishing a fast, flexible flow through the process is more important than the periodic interruptions caused by iterations (and the stop/start of iteration reviews / planning). There’s more to it than that, of course.
There are times where this is suitable and times when it’s not. If you are in an environment where making a plan and committing to it is not important, then what you describe doing seems entirely appropriate.
You’re also quite right that a team’s commitment to completing work needs to be met by reciprocal commitments from the business.
Matt,
We got once into quite similar situation as you, with user stories being under-specified and causing similar problems with estimation. In our case it was not due to the fact that our PO would have intentionally evaded his duties for the team, but more due to the fact that we had transition to scrum in middle of project and many user stories were formed from which were originally have been more technical tasks. In addition, there were many user stories that needed some prototyping before it really could be known which was the really desired result. Our savior was improving the acceptance criteria instead of concentrating stories itself. I, as a scrum master, went through backlog in good time before next planning going through the most important ones and doing bit of detective work to find out which user stories were too open and might have issues to understand fully. After that I went through the people who might know more of the idea behind the user stories and suggested some set of acceptance criteria. After I had basic set of acceptance criteria for upcoming tasks I went POs office to go those through. Usually few modifications were required for the set, but it was much easier for PO to go those through with me as we had some basic understanding clearly written which might be the point. I found out that in many cases, due the transition of the process from task based approach to story based, the PO was also bit unsure which each story reflected and by giving a bit of helping hand he was able to carry on with those. This really speeded up our planning and gave more value for team members and PO. It was good learning process for both me and PO and made us all much more effective on our work. My situation was of course different in that way that our PO was really dedicated, but the problem with missing detail could be addressed that way.
One question that pops into my mind is why PO does not seem to care in attending the planning sessions? Is it only lack of the dedication or maybe he feels the same problem with vague user stories and that he is missing vital information that he does not know how to fill and therefore does not feel like having anything to add, therefore feeling that he is just wasting his time?
Thanks Mike and H-P, those are helpful insights. I began to urge the development teams to ask for better Acceptance Criteria as we went along, but we even had instances where the AC had been agreed to at the start, and met by the team, only to have executives deem the results “a failure” due to other, unstated expectations on their part. That was just the sort of environment it was, and logic (as well as agreements between product and teams) often were thrown out the window later on.
As for the product representatives not attending planning, it was usually a case of them being over-committed. One product owner would have several products under him or her, and they’d also be expected to be in (other) meetings all day as well as traveling to the customer’s site. At times, it was also a case of the product people thinking that they shouldn’t have to spend much time with the development teams, which was even more worrisome to me.
Hi H-P,
This is an excellent point (about adding acceptance criteria to user stories). When I wrote the User Stories Applied book, I hadn’t realized the importance of these as ways to make sure stories are of a good size, well thought-out, and well-communicated between the team and product owner. I realized it between the user stories book and Agile Estimating and Planning and cover the subject a bit in that later book. I use the term “Conditions of Satisfaction” for these to make clear that I really don’t want acceptance test *cases*; I’m more after the test plan. I want the PO to have a discussion saying something like, “Well, when this user story is finished I would expect these things to be true: <list of conditions of satisfaction>.”
Thanks for bringing this point up.
On the Christmas present topic, at Atlassian we recently started a weekly “agile book club” for our dev team leaders, as a means of ongoing training & knowledge sharing. The first book on our curriculum is Agile Estimating & Planning – each week we read a few chapters on our own and then meet to discuss the questions at the end of each chapter (or, quite often, dive off onto vaguely related tangents).
As we’re rapidly reaching the end of the book, I need to come up with another one that will keep our busy team leads interested enough to keep showing up to book club. So I, for one, would be willing to forgo a novel or a DVD if I received a Christmas gift that matched the usefulness of AEP
That’s great, Melanie. Thanks for your kind words about that book. I’m hopeful my next one will be as helpful as people have told me that Agile Estimating and Planning was. You can see some draft chapters of my next book at http://www.SucceedingWithAgile.com
I, however, am still hoping for the Blu-Ray Godfather movies I dropped a few hints about to my wife!
I have heard the same from teams not wanting to spend enough time during sprint planning. I think it is because we are increasingly becoming ADD…:-) I am currently coaching a team. It’s been an issue with the team for sometime. We would quickly lose focus during the planning meeting and end up taking short cuts only to find out issues during the sprint. We tried both ways- 1) having people individually breaking stories (that they would work on) into tasks and estimate and then share with the team at the end, 2) having the whole team do the task breakdown on all stories together. We all agree that it worked well when we all did it together albeit it took longer. To make some senses of the time we spend during planning, I put it this way. Say a team spends 400 hours in 2-week sprint. Spending 4 hours is just 1% of the development time. Doesn’t it sound reasonable? In most cases when 4 hours is not good enough are when product backlog is not being groomed on an on-going basis. This is what H-P mentioned doing before coming to the iteration planning. We do pre-planning with the entire team. It is a weekly standing meeting for an hour. This allows the team to see what’s coming as well as the product owner to get an early feedback about the complexity of the stories.
Mike,
I have also found that continually breaking up stories into our based activities can get really repetitious, especially if you are just adding new functions to relatively stable and developed architecture. Eventually, many of these are stories appear to involve many of the same tasks (e.g. create x number of action classes, configure y number of OR settings, etc.)
Jeff–
That can be the case for some projects. Fortunately, though, when it is the case, that part of the sprint planning meeting usually takes only a few minutes.
Good day Mike,
Thank you for the great post. A team that I was part of in the past actually did complete Sprint [iteration] Planning without breaking down into tasks. It was interesting how we could come up with a few pieces of relevant information on each user story and a couple doodles then decide that was enough as a team. I must say this was a team of people who had been doing Scrum for over 4 years along with XP practices longer than that and were well seasoned technologists too. I have not been part of a team that has done this since.
We use high-resolution task breakdowns to make sure that everyone agrees on what needs to be done. I’ve been encouraging the team to do the bulk of the code design work for the iteration at this point, and then write very specific tasks (“add to_json method to Blog model” as part of the story “API access for blogs”). This is slow, but it ensures that everyone has an input on the design, and that tasks are interchangeable. We also tend to run into a lot of the edge cases we hadn’t thought of while discussing the story, which is nice, because the product owner is right there.
Mike,
Thanks for another great blog. This is not the first time I’ve seen you discuss the need for/benefit of design discussions in sprint planning. This is something that I regularly introduce with teams I’m coaching and I feel there aren’t enough good resources to point to on this subject. Unfortunately, it seems too many are out there suggesting a less than sufficient amount of discussion in planning.
I see too many teams breezing through planning and losing the opportunity to really make sense of the work they’ll be doing and coming away with a real solid understanding of their “commitment” (in quotes because I think this commly results in something less than true commitment).
Do you accept requests? I’d like to see a blog focused on sprint planning as a design session.
Hi Brad–
Thanks for your kind words. I am trying to figure out the best way to add a “request a blog topic” aspect to this site. I think the best is for me just to make a new entry and have people add requests as “comments” to the topic.
In the meantime, I’ll add writing something about sprint planning as design session to my list of topics to write about.
Hi Mike,
Excellent post. Our team (who you trained before I joined it) has also been doing what Chris mentions. As PO I would own the backlog and the stories in it. Devs would estimate the stories in points. Based on team velocity (story points per 2 week sprint) the team would commit to the top ‘n’ stories by priority.
The dev pair working on each story would then break it down into tasks (with hour estimates). Once number of hours remaining for all tasks associated with a story got to 0, we moved the entire story to “Ready for Demo” status. The Demo was basically an evaluation of our user acceptance criteria for the story and we could it “DONE” if the evaluation passed.
All in all, this process worked pretty well without us having to estimate at the hour level. Also we had very clearly defined boundaries, PO owned the stories and devs owned the tasks it comprised off. But as Chris said, all these devs were well seasoned, both as technologists and as SCRUM practitioners
Hi Mike,
Thanks for your great knowledge sharing. I tend to only have one sticking point in my mind when it comes to going from story points on the backlog to task hours in a sprint and would love to know what should be done.
It basically stems from the conclusion that people tend to either be chronic under-estimators or over-estimators – hence the use of story points and actual velocity in the first place to give a real estimate on completion date based on empirical data.
The confusion I have then is when a team commits to what it can achieve in the sprint by breaking stories into tasks and hours. This is then limited by available hours for the sprint (i.e hours of actual work each day * number of days in the sprint * number of people – holidays etc).
Now, what happens if the team tend to overestimate/underestimate, the velocity based on history says that they should be able to complete X stories, but after they break it down they say they will only be able to handle Y. Y may consistently be above or below X.
What should be done in this case? Do you resign to always pulling extra items off the backlog in the sprint once they finish early (in the overestimation case), or alternatively find that the burn down is never completely burnt in the sprint (in the underestimation case)?
Also, is it perfectly acceptable to change the story points associated to a story once further in depth analysis has been carried out in sprint planning or should these remain unchanged?
Thanks
Hamish
Hi Hamish–
Yes, if the finish early, pull in more work.
It’s OK to change a story point estimate but I caution to be very careful in doing so. If you change an estimate after sprint planning you will then calculate velocity using at least one user story whose story point estimate came after a great deal of thought. THis will tend to overstate or understate velocity relative to the product backlog items, which are each estimated without that level of thought.