My team is getting up to speed with Scrum, but most of us are more familiar with non-agile or "pseudo-"agile methodologies. The part that is the biggest hurdle for us is running an efficient Sprint Planning meeting where we break our backlog items into tasks, and estimate hours. (I'm using the terminology from the VS2010 Scrum Template; apologies if I use the wrong word somewhere.)

When we try to figure out how long a task is going to take, we often fall into the trap of designing the feature at the code level -- table layout, interfaces, etc -- in order to figure out how long that's going to take.

I'm pretty sure this is not the appropriate place to be doing that kind of design. We should be scheduling tasks for these design meetings during the sprint. However, we are having trouble figuring out how else to come up with meaningful estimates for the tasks.

Are there any practical habits/techniques/etc. for making a judgement call about how long a feature is going to take, without knowing how you plan to implement it? If our time estimates are going to change significantly once the design has been completed, how can we properly budget our Sprint backlog ahead of time?


Just to clarify, since some of the comments/answers are very valid but I think addressing the wrong question.

We know that what we're doing is not right, and that we should be building time into the sprint for this design. Conceptually all of the developers understand that. We also also bringing in a team member with Scrum experience to keep us on track if we start going off into the weeds.

The problem is that, without going through this design process, we are finding it difficult to provide concrete time estimates for anything. We are constantly saying things like "well if we design it this way it might take 8 hours but if we end up having to do this other way instead that will take about 32 but it might not be as bad once we start trying to write it...".

I also assume that this process will get better once we have some historical velocity to work from, but many of the technologies and architectural patterns we are using are new to us. But if potentially-wildly-wrong estimates are just a natural part of adapting this process then we will just need to recondition ourselves to accept that :)

  • What do you mean by "appropriate?" Apr 12, 2012 at 21:09
  • I mean that I don't think the team should be spending 25-30 minutes on the technical design of a feature during sprint planning, but that is just my gut feel (that it's making our planning meetings go way long.)
    – KutuluMike
    Apr 12, 2012 at 21:12
  • You're right Michael. I've just thought of something else which I'll add to my answer below. Essentially, if you are sprint planning without a business sponsor there of some sort, then you don't really know what to prioritise. More below.
    – Ian
    Apr 12, 2012 at 21:15
  • 1
    You have two choices. You can extend the length of the design phase so that you can get adequate estimates, or you can live within your self-imposed time constraint and accept wild guesses. You can also build time into the sprints for design (which you are going to have to do anyway), and amend your work estimates when the design phase is completed. Apr 12, 2012 at 21:16
  • I guess that "amend your work estimates" part is what is a struggle for us; some team members are more insistent than other that we not give hour estimates if we don't know they are right. I also hope and expect we'll get better over time but clearly, "everyone else" manages to do this just fine so I feel like there's something obvious that I'm missing.
    – KutuluMike
    Apr 12, 2012 at 21:19

6 Answers 6

  1. Schedule a recurring "grooming" meeting where you have these design discussions. The team I'm on has them once per sprint, on the day before planning. The goal there is to have the design far enough nailed down that the team can agree on the time estimates for the overall story. You could consider doing task breakdowns in this meeting, so that planning becomes purely an exercise in deciding how much to pick up. In other words you should be doing the design in the sprints BEFORE you start doing the actual work.

  2. Consider using planning poker, i.e. points/units of "effort" rather than man-days to estimate tasks. Also try to break down the stories as much as you can. The longer/more complex a story is, the less likely your estimate is going to be accurate.

  3. In planning, the scrum master should keep the planning on track by calling a halt to any discussions that get too far into "solving." At that point the team members are required to quickly come to an agreement on the estimate, usually giving an upper-bounds/worst case number. It's much easier to pick up more work if the tasks end up being easier than you plan, than it is to deal with schedules slipping due to tasks taking longer than planned and stories rolling over into multiple sprints.

  4. Talk about how the estimates panned out in the retrospective at the end of the sprint. Particularly if there were any that were remarkably far off. Did the team learn anything from how the story went versus how they expected it to go? The scrum master should keep the focus on actionable changes that can be made to your design/estimation process.

  • I marked this as the answer because it seems to get to the root of our problem: we need to do more up-front work before the planning meeting so that we understand the backlog items and the tasks involved better once we get there.
    – KutuluMike
    Apr 13, 2012 at 14:45

I think the issue is that you are trying to estimate time. Don't.

Estimate complexity. Look at a requirement, (hopefully a user story) and rate how complicated the team thinks it will be to figure out how to build it and test it, relative to how complicated other requirements or user stories are. Sometimes you'll be wrong, but often you'll get a good idea of how hard something is going to be. You'll also find that items that are the around same complexity tend to take the same amount of effort to complete.

So, complexity rankings become the "story points" associated with the user stories in your product backlog. After you work through a few sprints, you'll get an idea of how many story points you can get through in a sprint, and that is your velocity. At that point, you'll have a much better idea of how long each item will take.

I highly recommend Mike Cohn's User Stories Applied.

  • That makes sense, but we're trying to follow the VS2010 Scrum Template, on the theory that lots of smart people who know what they're doing came up with it. If we're not estimating hours, how do we track things like remaining work on tasks or produce a burndown chart?
    – KutuluMike
    Apr 13, 2012 at 0:10
  • You don't track remaining work on tasks. Either it's done or it isn't. At the beginning of a sprint, the team commits to getting a certain number of stories done, based on their priority, how complex they are, and the team's best guess as to how much complexity they can deal with. In the Sprint Planning meeting, they should decide what tasks are required to complete the stories. These tasks make up the sprint backlog--you can just say they are 1 point each for the sprint. As each is completed, they can be checked off as done. Apr 13, 2012 at 3:19
  • There doesn't need to be any relationship between the complexity points in the Product backlog and the task points in the Sprint backlog. You update the sprint backlog daily, checking off tasks. You update the product backlog at the end of the sprint, when you've demonstrated complete stories are done. Apr 13, 2012 at 3:21
  • Hrm, then we're really doing something wrong. I know there are more than one way to do Scrum but this is the guidance we're using, which says to track remaining work on a task: msdn.microsoft.com/en-us/library/ff731574.aspx. Is that not right?
    – KutuluMike
    Apr 13, 2012 at 3:41
  • 3
    Ahhhhh. I see. It's not wrong as such, but obviously it's not being particularly helpful to you. The Scrum Guide says "As work is performed or completed, the estimated remaining work is updated," so the MS template makes sense. Like I said, it's not really a useful metric though--nobody ever does a good job of estimating remaining work for a task, and you waste time trying to do so. Make your tasks small and binary (0=done or 1=not), and you've got a measure of what's done and what's left, and you don't have to think about it. Apr 13, 2012 at 12:01

I know your question is specifically about avoiding design in planning. But this is sort of an XY Problem.

I've been where you are. Rather than give you something that may provide an incremental improvement, I'd like to help you leapfrog some of those intermediate states.

Here are three things our team does specifically related to planning and executing work. These have helped us avoid design thrashing and escape from inaccurate time estimates.

Automatable Acceptance Criteria

Our stories are pointed by their number of Automatable Acceptance Criteria. This means, if we were to write automated tests to confirm that the story is done, what would they be?

For example, "When the user clicks 'play' on an iPad running iOS 6+, the video starts playing." It might be hard to actually automate this test, but it's an acceptance criteria (AC) of the story and contributes one point.

We use the Fibonacci scale, and we always round up. So if a story has four automatable acceptance criteria, it's a five point story.

Our maximum story point size is eight points, but we rarely have those. If a story has more than five automatable acceptance criteria, we find a way to split them up.


We have a kickoff meeting on Monday, but our grooming meetings are where team planning happens. Prior to grooming, team members will pre-groom a story by describing the outcome and taking a stab at the automatable acceptance criteria.

Grooming brings the expertise of the team to bear on the pre-groomed stories, ferreting out unspecified requirements, breaking stories up, etc.

We sometimes list tasks in addition to the acceptance criteria, but these are not time estimated. We never estimate time. Tasks are just statements of work that needs to be done in support of the criteria.

Limiting Work-in-Progress

Traditional scrum attempts to limit the time of work to the sprint duration. We found that this artificially caused us to rush to meet sprint deadlines, killing our weekends because the sprint ends on Friday.

Another approach is to limit the work in progress at any given time. We've migrated to the latter and have been significantly happier for it.

Once a story moves from the backlog into work in progress, we characterize it as being in one of several states:

  • On Hold - team work can't happen because we're waiting on some extra-team activity
  • In Development - working on achieving the acceptance criteria
  • Needs Test - we believe we've met the AC, waiting for someone else to verify
  • In Test - the story is being evaluated against the AC, bugs are being addressed
  • Ready to Deploy - at the next available opportunity, it's going live

We then use the number of stories in each state to drive the team's focus. For example, a developer may be available to take on a new story, but if we've got a lot of stories In Test, it's better for them help out on existing stories.


First, recognize that accurate estimates are impossible under those circumstances. Don't stress out if you get it wrong. However, you still need a rough idea in order to plan, and really the only way to account for complete uncertainty is to add more story points to your estimate. If you don't know if it's a 5 or a 13, use the 13.

It's also helpful to break stories down as small as possible. We often have a research/design story with the sole purpose of doing enough work to have a better idea of how to do the feature, then the feature story itself goes into a subsequent sprint. Think about why this works. Even if you have no idea how hard something will be, you usually know fairly accurately from past experience how long it will take to find out.


There are two things you can do here.

First have some sort of scrum master who's role is to monitor the discussion and say "Hey, you're designing again" when you are. It's harder than it seems, rotate people into it day by day and initially have everyone be the scrum master so anyone can pipe up.

Second, if you are designing during the sprint planning you need to be able to differentiate between not knowing enough to make a call on a task's duration, or whether you are just designing because it's more fun.

Again, the scrum master should kick in here and tell you to put the item back on hold until you know enough to schedule it, or get you to stop designing and answer the original question (How long will it take).

So if you are doing sprint planning, it makes sense to have a business sponsor there to go over the backlog with you and prioritise stuff they want to see done first. If you do that you will find it is harder to design during the session because they will get restless and eventually won't want to come.

  • We are actually adding a scrum master (someone with Scrum experience, hired to fill this role for us) so hopefully that will help; but we all recognize that this is a problem, what I struggle with is how to do it better.
    – KutuluMike
    Apr 12, 2012 at 21:17
  • Well, you've identified the problem. You design in the meeting. Next meeting you have, if you find yourself designing, stop, say "We don't know enough" or "We know enough". If you don't know enough, put it on hold until you have more info (Design session outside of the planning meeting) If you have enough info, schedule it (or not) and move on.
    – Ian
    Apr 12, 2012 at 21:19
  • One other comment I should add. Be careful when you hire a scrum master. With all agile methods, the key is to be flexible. Adopt what works, change what doesn't. That's a huge change for companies who like to have procedures documented and plans planned.
    – Ian
    Apr 12, 2012 at 21:21

We have been operating on the basis of estimating the story 'cold' during the sprint planning with just some limited discussion. The estimates are really quite inaccurate despite the setting up of teams with a reasonably narrow focus... mainly due to the existence of a lot of undocumented, uncommented legacy code with no real over all idea of what is actually supposed to be happening and a staff that has largely changed since the original was written.

What we are trying now is to spend some time ahead of planning investigating each story - and here only one dev will investigate one story... We hope that this will mean that the dev who investigated will be able to provide some clarification and insight to help the estimation. So far this has helped on the occasions it has been tried.

I have yet to be convinced that the additional investigation really makes the estimates enough more accurate to justify the cost but we will try it for a few sprints to see.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.