Story estimates in Scrum

Question

We started a project that will be managed with Scrum/XP. We wrote the whole product backlog upfront for evaluation purposes. We're making sure all stories are customer-centric and we're evaluating them by

• story business value: MoSCoW technique - Must, should, could, would/won't have this implemented
• story effort/complexity (= story points): 1, 2, 3, 5, 8, 13, 21, 100 - related to story complexity/effort rather than ideal days duration

100 story points may have some stories with Would/Won't have because they actually are bigger complex stories that will be broken down later if needed.

Calculated story importance is based on value&effort by not overlapping MoSCoW stories.

But without 100 point stories our stories so far (also broken down) has complexity between 2 and 8 which we think is an appropriate story size to avoid micromanagement. But some stories became related or dependant on each other. We have stories that may take more if done first, and less if some other story would be done before them.

Questions
Is it possible to adjust story points later on during development, as we can do with story tasks where we can re-evaluate them, add new, remove existing or is this not the case with stories? Because changing their complexity, will also change end date estimates based on planned velocity. What's the best practice in this case?

Answer 1

I can only describe my expirience.

When we were planning first sprint we decided that we could accomplish 18 points. So we took several stories and total estimation were 15 points. As I mentioned above we were making our first steps in scrum and that's why we decided that 3 unused points and form-factor 0.6 guaranteed our success.

But our estimations of each story were only approximate. We had also some dependent stories. And we didn't make plan of implementation of each story because we thought that it's unnessecary with agile methodology.

As a result we failed our first sprint with only 8 complete points.

Before our second sprint I decided that we should take something from old good simple cascade and iterative methodoligies (and I was a scrum-master). So, on our next spring planning to make correct estimations we planned each story (about 20 minutes per story), with simple diagrams, all dependencies, details of implementation and so on. The planning was difficult and it took 2 meetings.

But the second sprint was much better and we've done almost all (actually we've done all but with some bugs). I think that we'll take less form-factor in 3rd sprint and it'll be successful.

Answer 2

From your explanation you're doing a great job already. Of course there will always be stories with a dependency. Some may not even have directly visible customer value; i.e. the initial effort to set up an architecture and some frameworks). But if you leave them out you'll create a lot of technical debt. If you can, I'd suggest that you try to make the equation complete and somehow show the relation between the tasks.

For instance: - task 3 is 8 points if done after task 2, but 12 points if done independently.

This way the product owner will feel the pain of ignoring dependencies, but can still make a choice to do the most valuable stories first. If the product owner is sure that all of the stories make it in the next sprints, then you can steer to have them implemented in the most efficient order. For instance, by blocking items for which dependencies have not been fulfilled (i.e. you can only have the 'change my logo on website' feature after the story 'webenabled version' is completed.)

Good luck!

Answer 3

You absolutely can estimate your stories again and you should. The points are only locked when the team commits to them at the Sprint Planning Session immediately prior to the start of a Sprint.

One practice I've used is when doing the individual Sprint Planning you should evaluate each story again. The team learns over time and will become more accurate with estimates and identifying dependencies. Remember what goes into a Sprint is up to the team, the product owner defines the overall backlog. If the project is time bound don't try to make the estimates fit the End Date, if you do you are setting yourself up for failure.

Remember that with Velocity you start with a guess at what you can accomplish. It usually isn't until the 3rd or 4th Sprint that you hit identify a realistic Velocity that the team can manage. Yes this does mean that you may have assumed the team could deliver 20 points per Sprint and actually can only do 15 points. Yes that means delivery time goes out or stories fall below the cut line.

As for dependent stories you should work with your product owner. If the team talks to them you can usually rearrange stories. Most people are receptive to someone that tells them "If we do A now it will take the full Sprint, but if we do A later it will take 15% of a Sprint" that makes it pretty convincing.

A useful practice to try is scheduling the stories within the Sprint. During the planning session once all stories are validated and discussed the team pulls up a calendar and discuss when they want to have things done. By putting target dates on a calendar it helps to identify overlaps and dependencies between the stories. This can identify things that are serial in nature and may cause a Sprint to fail.

Hope this information is helpful.

Answer 4

There is a informative blog post related to estimated and planning: Sprint Planning - just in time just enough.