Make estimating easier

Break your sprint planning down.

Do you need to estimate the individual tasks? I’ve done sprint planning two ways:

1. Stories are estimated in story points and then tasks are estimated in hours
2. Stories are estimated in story points and tasks simply fall under that with no estimate

Of the two, I prefer the second option. I find that not estimating tasks gives more freedom to developers to cope with changes. If a task no longer makes sense (how many times have you found out that a task isn’t applicable or was already done in a previous sprint) you simply throw it out without any penalty, or you may have to change a current task into something new, possibly breaking it up. You’re really being redundant if you estimate both, as the sum of the tasks should represent the story points and vice versa. What value do you really gain by this other than knowing how much time individual tasks will take? If you find yourself with task sizes that really vary enough to make a difference, I would suggest breaking those tasks down into smaller, more homogeneous chunks.

By doing this, you can cut down on the time you spend in sprint planning. Stories get estimated during sprint planning, and when you start the sprint you can put down all the tasks you can think of that make up that story. Obviously if there are points that you come across in estimating the story that you know will have to be dealt with in a task, you can add that onto the story information and put it as a task.

Estimate in Ideal units

Story points are meant to be in ideal units such as ideal man hours or ideal work days. These are meant to mean that given the perfect day every day, where you had no interruptions, no meetings, and everything went according to plan, you could accomplish the task in X days. Now everyone knows that this simply isn’t true, but the wonderful thing about statistics is that it doesn’t have to be.

What I mean by this is that after a while of estimating these in ideal days, you realize that maybe it takes an extra 25% of the time you estimate on average to complete a story. Lets say you had estimated 4 ideal work days, and instead it took you 5. Over time, you keep track of this and then you have a rough idea of the conversion from ideal days to real days. Your first instinct would be to try and compensate for this by over estimating, and you would likely be wrong. The main thing here is to stay consistent. That way, your long term average remains the same. Sure sometimes, it’ll be under and sometimes it’ll be over, but the more you estimate, the better off you are. If you find that you still can’t get a decent estimate, maybe that means you don’t know enough about the story to estimate it properly.

Talk about the stories

When you estimate, everyone should have a rough idea of what will need to be done, from start to finish, of what it will take for this story to be complete. You don’t need to know every detail, but enough that you think you, yourself, could undertake the story. If you don’t have that level of confidence, you probably shouldn’t be estimating it. If you say “Well this story is too big for us to know most of the details” then that’s an indication that the story is too big, and should be broken down. Stories, at least in my experience, have been small enough that one person, if need be, could work on it alone and accomplish it within a week or two.

This also will help to solve your second point in the edit, which is too much estimation. Instead of estimating every single task for every single story, you simply estimate the story as a whole, which should help to remove a lot of the estimating. As for making the meetings less monotonous, I would suggest planning poker, which you can see more information about above.

Make planning more engaging

Estimate using Planning Poker

As far as making estimation more fun, have you tried planning poker? It’s the way that I’ve always done planning for all my sprints on multiple teams, and it’s a good way to keep everyone involved, as every person has to at least pick SOMETHING. There’s also a fair amount of fun involved when everyone on the team picks 3, and someone puts down a 20 and has to explain themselves, or when everyone on the team puts down a 5 but the manager puts down an 8 (who’s gonna argue with the boss when he wants to give you more time!).

To do this, all you need are some planning poker cards, which we often make on the back side of index cards, or using normal playing cards with values attached to face cards. Nothing fancy, and it keeps everyone focused. Just remember that trying to do any task for an entire day (including planning poker) takes a toll on productivity. Many sets of cards come with a coffee card for a reason; if someone is feeling burnt out, give the team a break to recharge and pick it up when everyone is fresh!

As an alternative to physical cards, you could also look at electronic cards. The real benefits here are automated tracking of results, tracking user stories to be estimated and allowing everyone to show their cards at once to avoid “cheating” (where one persons estimate is influenced by another’s due to being able to see their card). Obviously this requires everyone have a computer and the ability to focus on the task at hand though, so use it at your own discretion.

1. Why are the backlog items not inserted and prioritized before sprint kickoff? Wasting developers time is not fun. Let your team leads work with the product owner and project manager a few days beforehand to prioritize stuff. This goes for planning who is on each sprint team too.

2. Why is it taking a day to break things out into tasks? If you have a reasonably sized team (2-4 developers, .5-1.5 QA people per developer, 1-2 misc) then you should have 2-4 user stories this sprint. Spend 30 minutes or so with the product owner clarifying requirements, then 30 minutes or so breaking it out to ~8 hour tasks. Don’t enter the tasks during the meeting. Just agree as a team what the tasks are enough for sane people to understand them, who is responsible for them, and about how long they should take. Agree that “how long they should take (including testing)” fits comfortably within the sprint.

3. If it’s not just breaking things into tasks, what else are you doing? Sure, retrospectives can take 30-60 minutes, but will be shorter as the teams get into a groove.

So in summary – quit wasting people’s time and they’ll dread the meetings a bit less.
Beyond that, fun and comradarie in the team isn’t something you can address in meetings. Go to lunch together, joke around, mix people up to have better personality fits, have mustache growing contests… once the morale is up then people will naturally make sprint planning meetings more lighthearted.

Planning is one area of scrum where teams have a lot of flexibility. Try something new every sprint until you hit on something that works for your team.

Some successful ideas I’ve either tried personally, or heard about from other teams:

• Do user story creation and prioritization without the entire team. The product owner and/or scrum master can handle a lot of the busy work and just let the team tweak it.
• Make your backlog significantly longer than a single sprint. It can take a while to build it up, but if your backlog is long enough, planning meetings are reduced to making small tweaks or addressing recent business developments.
• Have estimation meetings separate from sprint planning. If people think the meetings are too long, there’s no reason not to split them up.
• Specifically plan breaks into the agenda. This is useful if you’re often wasting time waiting for one or two team members to return.
• Break in the middle of the meeting and assign everyone to task out one or two user stories, then meet back together to report and gain consensus.
• Make sure your planning meeting is about what to do, not how to do it. Engineers fall very easily into the latter. If you need to, set up separate design meetings where you discuss the how.
• Separate your stories into investigation and implementation. Planning meetings often go too long when team members know too little about what they will be working on, and try to figure it out during the meeting.
  For example, say you needed to integrate with an API that your team has no experience with. Rather than try to create estimates and tasks during the planning meeting about something you are clueless about, make one investigation story to learn the API, do a simple “hello world” app, and teach it to the team. Then you’ll be equipped to plan the actual work.
• Keep track during your meetings of specific issues. Not just “planning is boring,” but a level of detail like, “we spend a lot of time talking about unclear requirements, and no one seems to know the right answer.” Then discuss those specific issues in your retrospectives and brainstorm for specific solutions. Break your problem down until the pieces are easy to solve.

We hold our sprint planning and retrospective at the same time, and are almost always done in 90 minutes, but we are one of the faster teams. We do a big company-wide longer-term planning every 5 sprints that takes 4-6 hours. Every team is different, of course, but if you’re spending an entire day every sprint, there’s a lot of room for improvement.

Your planning sessions are way too long!

Based on my experience, a sprint planning meeting should take no more than 2 hours per week being planned (e.g. a 2 week sprint should take 1/2 day at most), but successful ones should be shorter than that (half of it).

In your particular case: why are you estimating tasks? You should estimate only stories during planning. Tasks can be estimated later by the specific task owners.

A way that worked for me:

• Quick intro to the sprint by the PO
• Estimation of the sprint capacity
• Stories run down and planning poker (timeboxed at 5/10 minutes per story) until there’s enough estimated stuff to cover the sprint
• Official commitment/forecast by the team

Then, in parallel/pairs/self organized at our desks, tasking and task estimation.

At my previous job, the entire first day of each sprint (we called them iterations there) was taken up with:

• Retrospective. We started out doing this in the afternoon of the last day, but we often found ourselves retrospecting about the sprint and then going back to work tying up the last loose ends of that sprint’s work, so we figured it would be better to make sure the work was all behind us before retrospecting on it. It also seemed logical to consolidate all the meeting overhead of the Scrum process so the other days could be planned and spent in more ideal terms. This typically took 2 hours.
• Sprint Planning. The backlog was estimated during a Milestone Planning Meeting (which could be an entire day in itself for both the Devs and POs), and had been prioritized by the POs prior to the beginning of each sprint. We figured out how many developer-days we had available (accounting for holidays, vaca, etc), grabbed the work we thought we could do off the top of the pile, and quickly reviewed the user requirements (previously vetted by our BAs) to get a more complete sense of what the work entailed than we got with the simple overview during the MPM. This typically took another 2 hours.
• Task Planning. Knowing the stories and acceptance criteria, we broke down each story into bite-size tasks estimated in ideal hours (an hour spent focused solely on getting that task “done” with no distractions or roadblocks). The way our point scale ended up being calibrated, a 5 was a developer-sprint, so a 1 could be anything up to and including two developer-days. For that reason, virtually everything had to be broken down in order for team members to be able to show progress on the scrum board. This was another 2-hour block, with some give-and-take between this and the next item.
• AAT Outlining. Our POs and BAs were not programmers and did not code. The POs hid behind a contract stipulating that they would deliver requirements in the form of a Word template and would work with the BAs to refine them in that form. BAs understood code, but their time was purely analysis and final testing (which required the system to exist, so they could record their macros into Selenium). So, to verify that our code would meet acceptance criteria when it came to that, we had to write our own AATs modelling the actions of the “paper” acceptance test. We typically did this in the same NUnit framework we used for unit and integration tests (we tried FitNesse and couldn’t give it up fast enough). This was the rest of our first day of each sprint and continued into the second.

In my current job, we’re still adopting the Scrum process, we didn’t have a team-wide milestone planning, and a lot of what we’re working on doesn’t have strict acceptance criteria. So, our sprint planning is as much an explanation of what each story entails and what we’ll call done as it is a commitment to grab the top X ideal hours of work off the top. We get away with it – for now at least – because we’re an in-house team and each of us works personally with the end users of our software to gather requirements and design solutions. Even then, sprint planning is an all-morning thing every other Monday, and the afternoon is spent clearing any personal roadblocks to being able to start development in earnest on Tuesday.

To actually answer the OP’s question rather than contrasting other comments/answers saying it shouldn’t be taking that long, there are ways to approach Agile estimation, sprint planning and retrospectives that are a little more interesting than you might be using.

Specifically addressing your concerns:

• Meetings are long – Time-box them. Each meeting, be it a retrospective, sprint planning, task breakdown, etc, should have a definite purpose and topic of discussion, and should be limited as much as possible to a set amount of time. It’s the Scrum Master’s job to keep these meetings on topic and rolling along to meet the time goals.

• Meetings are monotonous – There will be some of that; you’re working in bite-size chunks, one at a time, so you’ll be doing the same thing over and over. Keeping the team focused and driving toward accomplishing the purpose of the meeting will help.

  Something else I hear is that maybe your sprint planning meetings are trying to accomplish too much. At my last company, story estimation was done at “milestone planning meetings”, which happened about once a quarter and took all day. In those meetings, everything that had built up on the backlog that we hadn’t estimated was estimated in points. If you’re doing story estimation in points, and then task estimation in hours, you don’t want to do them both at the same time (maybe on the same day).

• Estimating stories in points, then tasks in hours seems redundant – They have two different purposes. The purpose of story estimation is to provide a rough estimate of complexity, that you can use to fill your sprint backlog based on past velocity and expected bandwidth. The purpose of task estimation is to break the stories down into things that take one developer-day or less (and so can be assigned to a single guy who would be expected to have it all done in time), and ensure you haven’t mis-estimated any story’s complexity nor bitten off more than you can chew in the sprint.

  If your stories all take one day or less, then it is redundant, but not all points scales are calibrated equally; at my last job, a 5 was two developer-weeks (because at the beginning we had a lot of epics to estimate), which on a linear scale made a point anything up to 2 developer-days. Given that kind of scale, virtually everything should get broken down into tasks. At my new company, a point is closer to half a developer day, so a 1 or even a 2 is definitely its own task, and 3-8 is nebulous with regard to forcing the team to split it up into tasks.

• There’s a vicious cycle of it taking longer making people less focused so it takes longer – Time-box your time-box. Take breaks, just like you should be when coding. Every 30 minutes, take 5 minutes to stretch your legs, regroup, etc. You can make it ten minutes every hour, but don’t push a solid block of meeting time too much further than that. Your guys might be getting hungry, or need more coffee, or a bathroom break, etc. Don’t deny them; if you make them suck it up you’ll find their minds wandering. Beyond that, keeping discussions short, sweet and to the point will help as well, as previously mentioned.

The Sprint planning meeting has 2 parts:

1. Decide what the team will do
2. Decide how the team will do it.

The first part is relatively straight forward–based on the number of story points the team feels they can take on, the commit to completing that many user stories in their order of priority. Done.

The second part is what developers should actually enjoy–elaboration of the story and designing the solution. The tasks fall out of that. So, have the product owner, or whatever SME he has provided explain a chosen story. Then have whichever developer wants to take it on, lead the design discussion. Use a white board. Bounce ideas around. Have fun.

That’s it, really. If design meetings aren’t fun, then there’s just something plain wrong.

Yea I know this is an old question, but I have a new answer. 😛

Split the meeting up.

We split our Sprint planning meeting into 3 separate mini-meetings

• Backlog grooming
• Story selection
• Task breakdown

We do each on a different day, right after our daily Scrum – as soon as the daily is done, we roll right into the planning activity, and then we are free from (regular planned) meetings the rest of the day.

So yea, we waterfalled our planning :-O

I’ll go into more detail about what is involved in each session in a second, but let me explain how we arrived at this.

We, like yourself, had a problem with really dreadful Sprint planning meetings. We had all the right elements, but everything just took forever and was really draining mentally and emotionally to get through.

Then I got this idea after reading this Business Insider article on Pivotal’s 5-minute daily about breaking our meetings up into shorter sessions and doing them at the beginning of each day.

I brought it up with the team at a retrospective. Some team members liked it right away, others were a little apprehensive, but then our intern mentioned some study he read about the pomodoro technique and started going on about it, and that really helped the idea gain traction.

So we decided to try it.
We broke our 2 hour meeting down into three 25 minutes sessions. (yes, that’s fuzzy math, but everyone felt our meetings were too long and only wanted to do it if we saved time).

And it worked!
We’ve been doing it for about 6 weeks now on two separate projects (6 two week sprints total) and it’s made a world of difference.
We are more productive.
We save a ton of time.
We get better outputs.
And we no longer dread our planning meetings.

And honestly, our 25 minute time-box is pretty loose – some sessions go really fast, like 5-10 minutes on some of our grooming sessions, and some go long, like when we end up identifying new stories or having to break stories up and re-estimate during negotiation. Overall though, it usually averages out to no more than 1.5 hours for the whole shebang, and I think that is why it works so well.

On to the details…..

Backlog grooming

Pretty simple – we review the top priority stories, talk about what they entail, and make sure our estimates are good.

We’ll re-estimate stories if needed – like say we estimated something months ago and after realizing what a similar story actually took, we might agree to re-estimate. (we use unit-less story points by the way, and we don’t estimate tasks).

Also, if the PO has added any new stories that he feels are high-priority, this is the time to estimate them.

Because we don’t do Story selection until the next day, this process gives the PO a little extra time to do make final judgement on what’s most important to get done in the next iteration – and this has proved very helpful.

This meeting tends to run short with some PO’s and long with others. (personally, I think it’s a great smell indicator of how your PO is doing)

Story Selection

Get your Chris Voss on, it’s time to negotiate.

At this meeting, we take the top priority stories and define a DoD for each. We negotiate what each will entail – splitting and combining stories as needed – until we can all agree on our Sprint goals.

We benefit a lot from having fresh minds and that good morning energy for this meeting – and knowing we will do tasks another day allows us to spend the time we need to really negotiate well and understand our commitments.

Tasks

Okay, so I’ll be the first to say, tasks was my LEAST favorite part of planning in our old one day meetings.

We just never hit our stride with this.
We tried saving tasks til the end of the meeting – but we were all just drained by then and it was really unproductive.
We tried defining tasks at the same time as our DoD during our negotiation, but we found it too distracting and too cumbersome – we would burn ourselves out before selecting all the stories. Also, it was really hard to keep switching focus/thinking back and forth between estimating, negotiating, story selection, and task generation. We struggled, and it sucked, and it made our meetings dreadful.

But now, by defining the DoD on one day, and not doing tasks until the next, we don’t get burned out, we’re always in the right mindstate, and it gives us a whole day to marinate over the story and really think through and understand all the tasks before we get started.

This alone, IMHO, is a total game changer.

Putting it all together.

So, here is what our Sprint ceremony schedule looks like now:

• Monday – Daily scrum -> Sprint review
• Tuesday – Daily scrum -> Backlog grooming
• Wednesday – Daily scrum -> Story selection
• Thursday – Daily scrum -> Tasks
• Friday – Daily scrum -> Retrospective

It’s worked really well for us.
If you give it a shot, I’d love to hear what you think.

We are having a weekly sprint with a one hour meeting in which we discuss the previous sprint, what is left to do and then move on to the planning of coming week.
All within one hour.

This is of course because we found out that in our case following scrum too strictly would only waste too much time. That is because most stories are already discussed with our team members when the requester creates the user story.

I’m just saying that if your team dreads planning meetings, you should probably let go some of the “rules” of scrum.

This question has been answered comprehensively, but only one thing is needed to make it work and be fun.

Give power to the team. – i.e. make them work on things that they think are the most important.