Constantly under-estimating user stories

Question

I'm the dev manager in my company. We're following what some people in the company like to call "scrum" but is in fact waterfall in scrum clothing - we are using some scrum terminology (backlog, sprints) but the PM, QA, and dev function as three separate entities in the delivery process.

This is roughly how our cycle looks:

• Our development sprints are 5 weeks long, followed by QA sprints of equal length in which the full sprint content is tested.

• We have a constant stream of "polishing" bugs (minor changes in UI layout, changing strings, etc.) as well as "major" bugs that are relatively small to fix (e.g. a missing null check that causes a user flow to fail). We allocate roughly half of the sprint for such bugs, customer cases, etc. and the other half for implementing user stories. The bugs work is estimated in a single "bugs bucket" work item per developer which is ~10 days long.

• In the beginning of the sprint devs get a prioritized list of user stories with a reasonable amount of detail.

• We have about 3-4 days of planning (that are part of the sprint) in which the user stories are assigned to developers and are broken down by those developers into tasks of no more than 3 days. Devs then commit to the user stories that we think can fit into the sprint.

The main difficulty, as I see it, is that we can't seem to properly estimate how long user stories will take. It is very common for user stories to slip out of the sprint because of an over-optimistic estimation. This consistently happens sprint after sprint. Now, while we do have some junior and new developers, I don't feel the problem is inexperience with the product because the same happens to our experienced developers. The result of this is that we increase our sprint length (it went up from 4 weeks to 5), but then of course the user stories got larger so this negated the effect.

My belief is that the user stories are too large. For example, it is common for user stories to be estimated at 20-25 man days (divided to two developers, e.g. GUI and backend) or even more (one recent user story ended up taking something like 70-80 man days, and its initial estimate was about half of this).

My feeling is that these user stories are too large and need to be broken down, but our PM strongly objects to this on the grounds that breaking down these user stories will result in stories that have no customer value (for example, in the 70-80 day user story I've mentioned, there was a lot of GUI work, a lot of backend work, a lot of DB work, etc. - but the user story would be completely unusable without any of these).

I was thinking that perhaps devs should force the US to be split to development milestones (rather than customer-facing milestones) and shrink our sprint accordingly, but I can't quite convince myself that this would help. I do feel that it is easier to estimate four 20-day items, since we have the data of the first item when estimating the second, but I am not sure it will give enough benefit.

I realize that fully analyzing our development process and finding what can be improved can take a significant amount of time and might be better-left for consultants rather than an online forum, but I feel that our problems should be fairly common...

Any input would be greatly appreciated.

Answer 1

You are right and your stories are too big for your iterations:

• Either your PO is right and the stories are monolithic (very unlikely in my experience) in which case make your iterations 6 weeks
• Or your stories are way too big, break them down.

The classic mistake is for product owners to go down the slippery slope of "nobody would want an improvement of so little value", thus bundling a bunch of subfeatures together in order to accumulate significant value to release.

It's much easier if I explain myself with an example.

Suppose this bundle of stories has the theme "Add a search feature to Stack Overflow". One could argue that unless we can do full-text search of all pages of the site, the search is not valuable enough to release.

They would be wrong. In fact, that's not what Stack Overflow did.

What we did was^(*):

1. release a simple SQL Server full-text search,
2. which was then enhanced incrementally with different filters etc.
3. once the simple solution was not adequate anymore, we refactored the architecture to use Elastic search.
4. then we extended the solution to cover new areas of the site as needed

All of these increments were (or could have been) released independently and provided value to the users of the site (either in terms of new features or better performance).

I believe that in your case you are trying to deliver the equivalent of all the steps above in one go. In a way, you should not be surprised because you have 5 weeks of testing in order to release something, whereas we try to be very lean and release 5 times a day on average.

So as you said, you are really working in a rigid (opposite of agile?) environment. In this case you shouldn't get hooked up to the letter of scrum: you are already adapting it instead of adopting it (pardon the pun).

What you can do, is simply slice your megastories vertically and focus on providing minimal value for each slice. Value is not necessarily "making the customers happy", sometimes it's merely giving them something "better than nothing" or even features that elicit "I won't use it" instead of "your product is now worse". As an example of why "I won't use it" is still value: a search that only works in simple cases might be almost unusable for power users, but it still provides value in some edge cases.

What you shouldn't do is slicing your stories horizontally, by developer milestone or tier or layer. In that case, those splits do not provide value, are not INVEST stories but tasks.

As @iArunraj said, there are also other issues that you need to address but the above is the solution to the specific problem you mentioned.

^{(*) This is a vast simplification, but accurate enough for the purpose of this answer}

Answer 2

The problems which I found in your process are

1. Rule of Scrum is Sprints should not be more than than 1-4 weeks. Ideally the Sprint should be 1 or 2 weeks for better tracking.
2. Sprint Planning should be made before the commencement of Sprint not during the Sprint
3. Once you commit the features to be taken up in Sprint, for no reason it should be changed. No addition/ deletion of features. If there are any important feature that can be taken up only in next Sprint
4. When you estimate a feature ask your team to estimate, the person who is going to develop that particular feature should estimate that feature. In that way we can avoid over/under estimating
5. User Stories should not be longer, it should be broken down into as smaller tasks as possible
6. Testing team and Dev team should work together in Scrum, After completing each feature/user story the testing team should test and report bugs. The bugs that can fixed in that sprint will be fixed and the bugs which cannot be fixed will be taken in next Sprint. In next Sprint priority will be given to bugs depending on its impact.

Solutions:

1. Plan your Sprint for not more than 2 weeks.
2. Assign a Business Analyst/Scrum Master to manage these process of Scrum. They should ensure the process compliance. He should be the person communicating to product owner or project manager
3. Train your dev team on estimating the features. There are many methods of estimations techniques
4. User Stories should be written by Business Analyst according to Business Needs. It should be smaller and simpler. The user stories should be prioritized based on Business needs and should be taken based on that priority.
5. Testing and Dev team shouldn't work as two different team, they should work as one team.

For more details on Scrum process, please check this link

Scrum: http://agileevangelists.wordpress.com/2014/01/23/intro-on-agile-scrum/

Answer 3

Smaller user stories and better estimates

Let me address your two main problems.

My feeling is that these user stories are too large and need to be broken down

Here are some specific tips for splitting larger user stories:

1. Patterns for Splitting User Stories
2. 8 useful strategies for splitting large user stories (and a cheatsheet)

The main difficulty, as I see it, is that we can't seem to properly estimate how long user stories will take.

Breaking down user stories into smaller ones will help a lot in better estimates. In addition, you can try the following:

1. Planning Poker: Planning Poker in Scrum brings together multiple expert opinions for the agile estimation of a project.

2. Research stories (spikes): If there is much uncertainty about the estimation of a story, you can take a time-boxed (typically no more than 4 to 8 hours) research story first. By spending this time the team gets a better understanding of the work to be done and can arrive at a better estimation.

Answer 4

My feeling is that these user stories are too large and need to be broken down, but our PM strongly objects to this on the grounds that breaking down these user stories will result in stories that have no customer value...

An eighty-day chunk of work that can't be broken down into pieces individually having customer value? That has never happened in the history of the world. Your PM (who you should be nudging into being a Product Owner, by the way) is probably thinking of "customer value" as "something I can definitely get someone to pay for", as opposed to, "something I could give away free and customers would thank me".

Say you want to add sorting to displays in your product. What if you started with alphabetic-only sorting? Well, maybe nobody would pay you for that on its own. But if you already had numeric sorting and geographical sorting in the product, and then you added alphabetic sorting, which would be the more likely customer reaction: "Thanks!" or "You Suck!"? So while alphabetic sorting has little value on its own, it still has some.

One approach to stories that are too big is to assemble stories from little pieces, instead of splitting stories out of a giant one. The key to this is scenarios: get your PO (sorry, PM) to state the story as a bunch of scenarios in Given-When-Then format, unambiguously saying what the product should do in a bunch of cases. (This alone may lead him to split the story, from fatigue: "Just do the ones we came up with, I'll deal with the rest later.")

Once you have the little pieces, some scenarios will obviously have affinities with others: "Given I'm an Admin" goes with other "Admin" scenarios, and not with "Given I'm a User" scenarios — put the "Admin" scenarios together into an Admin-focused story. "When I choose Sort By Name" goes with "When I choose Sort by Price", and not with "When I choose Reset" or "When I log out" or "When I enter a search term" — put the "Sort" stories together into a Sort-focused story. And so forth.

Another way to force stories to be split is to let the time-box do it: you can't finish an eighty-day story in a two-week sprint, so you're going to have some of it done and some of it not. Press your PO (sorry, PM) on what part he would most like to have in hand when the two-week axe falls. (If he says something like, "The database part", introduce him to vertical story slicing.)

Other valuable approaches are either included in or referred to by the other answers to your question here.

More information about slicing stories and writing scenarios (e.g. for Cucumber or FIT) is just a web search away.

Answer 5

I would like to add a point to the great answers already here: if you're consistently under-estimating stories, I'd say that it's possible that you're estimating them correctly but over-estimating your velocity. Try to get rid of estimating things by "days", and start estimating them by points instead. Estimate tasks based on relative size compared to each other, preferably with the fibonacci number series to avoid pointless tasks like deciding if a story is 28p or 29p in size. Then it's just a matter of finding the amount of story points a team can commit to each sprint (their velocity) to find what a good commitment for that team is

That is, of course, a footnote compared to the bigger issues that already has been solved in other answers in this thread.