Story estimates in Scrum [closed]

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?

Ammoniate

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

@VadimKotov this would belong to Project Management or even Software Engineering, but since it's too old, I'd leave it open. – Retinoscope

@Korcholis we are working on closing old off-topic questions too. It could be locked for history though (in closed state). This is done to prevent new answers and new similar off-topic questions – Acosta

@VadimKotov that's nice then – Retinoscope

Answer 1

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.

Yates

My estimates aren't based on duration but rather on complexity so I suppose I'd change points in case we really missed story's complexity. I think this should be rather rare. But thanks for your input. – Ammoniate

The estimates shouldn't be based on duration, they should be based on complexity. Maybe I misunderstood the question. But simply put, until the story is being worked on as part of a Sprint it is acceptable to repoint/rearrange as long as the product owner is Ok with it. That's the nice thing about agile anything on the backlog can be changed until its part of the current Sprint. – Yates

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!

Blau

We call these stories "tech stories". We didn't plan any, since we already have majority of the fundamentals done. Outstanding ones will be done within customer-centric ones. – Ammoniate

Regarding double estimates is a bit tricky ie. Since we first work on stories that have the biggest value ans least effort it may happen that Story2 will come before Story1. But in that case you'd use higher complexity and you'll have to reorder... I guess automation in this case is out of question. But your suggestion with double estimates is ok. We'll just add that in comments and use it when sprint planning. – Ammoniate

Answer 3

There are some patterns that would help you in splitting User Stories in a way that they would remain INVEST, which means you would try to save dependencies, size, testability and value in particular. You can read more about that here: http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/ Richard is actively applying and improving them, and he is not alone ;-)

Just be aware that splitting and keeping dependencies (which is like creating a critical path in a Gantt chart) is going to trump the capability of the team to be creative, and to negotiate on those stories, and might also hide a "non-valuable-proposition".

HTH
ANdreaT

Torus

Answer 4

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.

Grumble

So did you actually change story points? Do your story points relate to complexity or duration? Based on your actual velocity your end date also changed considerably. – Ammoniate

No, I didn't. New problems which occured during implementation we interpreted as new stories with high priority (like bugs). But, imho good difficult planning is vitally important in scrum. – Grumble