Scrum backlog sizing is taking forever [closed]

Question

I work on a huge project. While we program we end up meeting for endless backlog sizing sessions where all the developers sit down with the team and size user stories.

Scrum doubters are saying that this process is taking too long and development time is being wasted.

My question is how long should it take to size a user story on average? And does anyone have any tips to make these sizing sessions go quicker?

Laurin

Why did you make this a community wiki? – Alaska

I'm voting to close this question as off-topic because it's a project management question not specifically related to software development. – Pedagogy

I'm voting to close this question as off-topic because it is not about programming. – Marquittamarr

Answer 1

• Only focus on the user stories for the next sprint
• If you need some estimates for the stories in the future use T-shirt sizing only
• Time-box your estimation session and ensure enough analysis was done up-front (but be careful, do not make big-analysis-up-front, only enough to understand the user stories in question)
• Use planning poker
• Break stories down and if it takes too long, break them again but try to keep vertical slices of functionality, refactor your stories if they are difficult to understand
• Have someone experienced facilitate the planning meeting

Your planning session for a two-week sprint should not take more than 1 hour but it is not unusual for it to take 1 day when you start with Scrum. Just practice and don't leave the analysis out.

The planning meeting is, after all, primarily a learning opportunity so if you focus on understanding what work need to be done (and how long it is going to take as a by-product) you are not really wasting time.

Raggedy

I like the T-shirt sizing idea... Clever! – Tchad

Answer 2

We size a user story in about 30 seconds to one minute.

We discuss the basics of what the user wants. Very little time is spent on how it will be accomplished. If you get too far into how it is accomplished then you are tasking out the story, which is a different activity.

The most that should be discussed about the "how" for the story is any risks (like the story using a technology that no one on the team has experience with).

This is the key to sizing not taking forever. You are not there to design the whole story. Just to size it. Get a basic idea of what will need to be done and leave it at that. Defiantly don't end up arguing over how the story will be done unless there is a significant time difference in the different approaches.

After a brief discussion everyone picks a number (using story point cards or just in their head). You then show the number and discuss any differences.

After a short time of discussion a consensus needs to be reached.

Another key thing is to not size stories that are not in the current or upcoming epic/release. Scrum changes too fast to waist time sizing a story that may be eliminated or broken up.

Alaska

I would be careful about not sizing further down the backlog. It can be very helpful to the PO to have an idea of how expensive a story is when he is prioritizing the work. Also, if you don't have the backlog estimated, the PO cannot plan/predict the approximate release dates for future features based on velocity. – Distant

understand the story - size the story - discuss the difference - re-size to get a consensus -------------- How could this process be done in 30 seconds? we usually spend 2-10 minutes for each story based on the complexity of the story – Jesu

Well, since we have all been on the project for a while, we usually know what the story basically entails (so understanding the story is not hard. Just read it, which takes about 15-30 seconds.) We all then pick a number and show it. Frequently the numbers are the same. If they are then we are done. If they are not, well, I did say 30 seconds to 1 minute. That is where the extra time comes in. The person most different from the rest briefly says why they voted as they did. We usually quickly reach a consensus. – Alaska

If it is taking you too long to do this then I would say your stories are too big or you are designing when you should be sizing (though 2-4 minutes is not too long.) – Alaska

Answer 3

Scrum is a very customer based methodology. Who will you deliver it to? What is their highest priority? Also, you don't need to make user stories for items that are unlikely to be done any time soon. Sure they need to be done some time, but you just don't have time right now.

How long is your sprint. Two weeks? Spend two hours going over the tasks for the sprint with your developers. Ensure everyone has their 60-70 hours of work (never give 80, or you'll just bomb...) and then the scrum master can focus on user stories. If you have a backlog that big, you probably need a product manager whose job is to interface with the customers and manage the backlog.

In short

1. Make a back-back-log and put things that you're not doing any time soon in it. Handle them when customers bring them up.
2. Ensure the developers have tasks to work on for the sprint. Focus on this sprint now and next sprint once this sprint has actually got started.
3. User stories are important, no doubt. But do all the developers need to work together on every story? Stories shouldn't be the developer's job. They should be the manager's/customer's job. If the developers have to do it, either forego the user story (if you can generate the user story from what the developers already have available, it's not very useful, since it isn't a "user" story!!!) or have the developer write one up quick and get it approved by the scrum master.

Edit: I thought you were writing user stories, not sizing. My bad! However, points 1 and 2 still apply.

Denitadenitrate

Answer 4

This is what I do:

• Limit your planning poker sessions to 5 developers. Try to pick representative ones (experienced, not expercienced, big mouth, shy, etc.). Rotate them often (don't pick the same each time).

• If it takes too long to describe your user story, it probably means that the user story has been poorly written. Improve your user stories. Having well written user stories is VERY important. A typical user story should be sized in less than 3 minutes and two cards passes. Sometimes it's a lot faster, sometimes it's a lot slower.

• If you have user stories that are too big (in amount of work), split them. If you get estimation above 13 "work days", your user story is the problem.

• If you have really too much user stories, do a pre-prioritization before estimation sessions based on the business value. You will adjust the prioritization later. I usually split the project is components because of that. If there is still too much user stories, you may need be understaffed and you need to create a second team.

• Your team will estimate faster with time

• Timebox your planning poker sessions ! If it lasts too long, involved developers get bored and it makes the meeting even longer... Literature tells you to timebox them to 4h. IMHO and with what I've observed in my scrum teams, it's far too much, at least in European teams. Try 2x 1h with a pause.

• If all of this don't work, hire an experienced Scrum Master (more than 3 years full time & active Scrum Mastering in similar project size as yours). If it don't work after that, stop using Scrum. Scrum can be very destructive in some companies, especially in the public sector.

Stock

The idea of rotating developers through planning poker sessions scares me. How do you establish a credible velocity if it's not a reasonably static team? – Tartrate

How do you establish credible estimation if it's always the same developers that estimate? – Stock

Answer 5

Scrum doesn't allow to take forever. Scrum has time-boxes for every meeting it has to conduct.

1. Sprint Planning Meeting should be 8 hours for a monthly Sprint (or less proportionally to the Sprint duration;
2. A Sprint can never be larger than a month, but can be two weeks;
3. The Daily Scrum time-box is 15 minutes, can always be less if all the time is not required;
4. The Sprint Review Meeting is 4 hours for a monthly Sprint, and less for shorter Sprint;
5. The Sprint Retrospective Meeting is 2 hours or less, for a shorter Sprint;

In my opinion, it doesn't use a purpose to take forever. Scrum prefers to respect the timeframes. If no decisions has been made as of what is the most crucial Product Backlog item to begin with, the Team then chooses the top most items (as much as the Team think it can deliver in one Sprint), and go with it.

It serves no purpose to take forever, under the risk to repeat myself, as this will only lead to more and more confusion among the members of the Scrum Team. Remember, management has no role in Scrum, so they are "chicken", they have no rights to speak, even the CEO! If the CEO has something to say, he has to tell the Product Owner, and it is the Product Owner's responsibility to see how he can have the best return of value from what is being done. And he is the only one allowed to interupt a Sprint, what is generally not necessary due to the short time Sprints take.

Haakon

Answer 6

1 minute; more than that and your stories are too big. If there is a lot of discussion about every story then your SM needs to help your PO to write smaller/better/concise stories.

Epics that the PO wants worked on should be broken down to small chunks before the sprint planning meeting. My guess is that you don't have good quality stories to size and your PO might need help in getting that part right for you.

I'm not sure what you mean by "endless sizing sessions". Your sprint planning meeting for a 2 week sprint should be timeboxed at something <=4 hours. Why is it endless?

Distant

If you break the large story into smaller ones, then you have more stories, which means the overall time spend on estimating story does't change – Jesu

I don't find that to be true. Just like a size 8 or 13 story is more complex to build with more unknowns; estimating them has more unknowns and thus leads to more discussion. Small stories like a 3 or a 5 are pretty cut and dry resulting in less need for team discussion and there is less size disagreement. – Distant

I agree with DancesWithBamboo. Smaller stories are also much more accurate than 1 big large story. It is also more beneficial to have smaller stories for relative estimation comparison. – Baedeker