10

I'm a PM on a large multi-year project with a sizable backlog of work implementing Scrum in 4 week release cycles. I hold weekly backlog grooming sessions with the project team and key business owners to review the user stories in the backlog, break down larger user stories (epics) into smaller ones that the project team can begin implementing in the sprint and size these smaller user stories using story points.

The use of story points associated to a user story is a fairly new concept to the team and has only been implemented in the past 6 months of the project (that started 1.5 years ago). So, the entire backlog is not sized in story points.

My goal initially was to introduce the team to story points and to establish a regular meeting for the team to size user stories in the backlog so that they get used to it and thereby become more efficient (read faster) at sizing. However, the team has plateaued in terms of the speed at which user stories are sized and at the current rate I estimate it would take upwards to another year to size the entire backlog.

Is this a good approach to sizing an entire backlog (that is very large) with the project team? How can I move forward with this in a manner that will speed up the process? If not a good idea, what is the better approach to this process?

Improve this question

4 Answers 4

Reset to default
6

Usually, it is not a good idea to frequently check the whole backlog with the whole team. The last 2/3 part of the backlog is going to change in the future and checking these items just waste the time of the team and generate unnecessary discussions about future issues which may not be implemented at all.

The recommended approach is that the Product Owner checks the whole backlog and keeps it in shape, and prepares as much user stories that the team can handle in 2-3 sprints. The rest remains in a kind of unknown or draft state.

The Product Owner can call for a regular meeting where the whole backlog is discussed where the team gives a rough estimation on the whole backlog. If the sprint is 2 weeks long than this meeting shall be called once in two months. This meeting gives an overall view on the whole progress and provides. Running this meeting is a bit different from a Sprint Planning Meeting, because it is longer, because of the number of user stories, and there is no task break down. If impediments or issues come up, the Product Owner shall sort them out. This meeting is often called as Release Planning Meeting (there might be some good articles about it on the Scrum Alliance site).

Improve this answer
3
  • Assuming that 2/3 of the backlog is not sized, how do you use story points to forecast completion of the total project? (FYI ... essentially, we're using SP in the way you are mentioning to forecast the next 2 sprints of work, but was wondering how this would translate to full project forecast)
    – KirMasAna
    Commented Oct 4, 2012 at 11:58
  • You shouldn't use the story points for forecasting, because they have nothing to do with time. Of course they do on paper, but in the real life they are closer to complexity.
    – Zsolt
    Commented Oct 4, 2012 at 12:43
  • I'm interested in hearing further on your perspective here. My goal initially was to establish average velocity (in SP) per sprint of the team and then use this as a forecasting metric against the rest of the backlog (assuming that is also sized in SP). Are you suggesting a different way to approach this?
    – KirMasAna
    Commented Oct 4, 2012 at 17:35
5

Stories to be worked on in the upcoming sprint should be estimated much more rigorously than stories scheduled for many months' time. Some people call this "Rolling Wave" planning.

This is how I've estimated the whole backlog in the past:

  1. Product Owner identifies stories and prioritises them.
  2. Before a project starts, the PO and 1 or 2 technical guys spend 10 secs per story on estimation. Literally just a buest guess from the headline of the story. Not very accurate, but accurate enough given that most stories will get changed in some way before development, and many will not even get scheduled in.
  3. At the start of the project the whole team estimates the candidate stories for the first sprint, and possibly the following (if there's time).
  4. During a sprint, take some time out for the whole team to estimate the next batch of candidate stories for the following sprint in more detail. (This meeting is timeboxed to 1 hour).
  5. Re-estimate stories if necessary during sprint planning.

Remember that Scrum is adaptive rather than predictive -- you shouldn't expect highly accurate estimates for work which is more than a sprint or two in the future. The type of accuracy you get from the above approach still lets you draw product backlog burndown (or burnup) charts to give an idea of release date.

Improve this answer
2
  • A couple questions: 1-often the SP size is an input to prioritization, how does the PO prioritize if the backlog is not sized? 2-how is the release burn-up done this way if the SP on user stories changes over time? Maybe I'm mis-understanding you, but I've operated under the assumption that SP attached to a user story shouldn't change unless there is signficant information that change the fundamental understanding of what the story represented from a functionality perspective (i.e. - it's really a different story in this case).
    – KirMasAna
    Commented Oct 4, 2012 at 11:48
  • Hi, 1. The PO prioritises by customer value initially, but can reprioritize when an effort estimate is in place. 2. The release burn-up is updated on a regular basis. If the SP changes, so does the chart.
    – MelR
    Commented Oct 4, 2012 at 20:09
4

I truly believe that story point estimation should be limited to tasks you plan on putting into the next two-three sprints. Attempting more than that is just going to waste your team's time. The further into the future you're trying to predict, the more uncertainty there will be. This is just the way it is, whether using Scrum or any other methodology.

So what do I do? Default new user stories to the average effort point value of completed user stories. You'd actually be quite amazed at how accurate predictions made with this value are, especially if you're good at breaking your epics into the right sized chunks. Just make sure that you don't fall into the habit of leaving this value. Estimate effort points with the team during sprint planning (or whenever you normally do it), but concentrate their efforts on the top of the backlog.

Improve this answer
3
  • I see the value in taking the average effort point value of completed stories for new ones. This is something I never thought of before, thanks! How do you handle a large backlog of items at the beginning of the project (or in my case, a project that has a large existing backlog but was not sizing user stories with story points). These aren't new user stories and since they were formulated at the beginning of the project, the assumption that user stories are broken down into roughly similar sizes may not hold.
    – KirMasAna
    Commented Oct 4, 2012 at 17:51
  • Depending on what you are using to manage your backlog, mass edits may or may not be possible. If they are, I would suggest still using the average value and simply updating the entire backlog at once. Accurate? Not really... More accurate than nothing? Yep. Just make sure your team is still revisiting the "default value" of upcoming user stories on a regular basis.
    – Andrew Clear
    Commented Oct 4, 2012 at 18:23
  • As an aside, this isn't something I would personally want to implement. I would rather the effort points be blank, than contain a default value. I offered this advice based on your question that seemed to imply you wanted/needed values for your entire backlog.
    – Andrew Clear
    Commented Oct 4, 2012 at 18:24
3

Affinity Estimating could be an appropriate technique to use here. Essentially, you put all your backlog items on index cards and have your team put them up on a wall in order of relative size (for example, larger items on the left and smaller ones on the right). You are creating a continuum of story point sizes. Then you can create dividing lines to represent your different size values (1, 2, 3, 5, 8, etc) and get agreement that items are in an appropriate grouping.

This is described in more detail in the following blog posts:

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.