How do we provide valid time estimates during Sprint Planning without doing "too much" design?

Question

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?

EDIT:

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 :)

Answer 1

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.

Answer 2

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.

Answer 3

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.

Pre-Grooming

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.