Scrum backlog sizing is taking forever [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 5 y开发者_StackOverflow中文版ears ago.

Improve this 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?

---

• 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.

---

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.

---

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.

---

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.

---

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?

---

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.