• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.


Sizing Backlogs With Diverse Products And Team Skillsets

Page history last edited by David Fox 11 years, 5 months ago


David Fox, State Farm Insurance Cos., and  the right others ...


  •  Finding it hard to keep a backlog relatively sized when there are a diverse set of products in the backlog, especially when the team members/skillets to work on them are equally diverse.
  •  For example, a Java developer isn’t going to know the size of a UI related story relative to a story to be delivered by a COBOL host developer for the backend.

 “Multiple backlog” approach:

  •  More than one backlog is maintained.
  • Each backlog is aligned to a specific team/skillet required to deliver the related products.
  • For example, one backlog contains the Java/UI stories and is sized by team with those Java skills.  Another backlog of host backend stories is sized by the team with those COBOL skills.

 “Don’t size by points” approach:

  • Team talks consciously what feels like more or less work.
  • Sizing is in more general terms (i.e. High, Medium, Low) effort/complexity.
  • Sizing occurs through categorization, grouping stories that are similar together.
  • Doesn’t worry so much whether stories are really relative or not.
  • ScrumMaster could size in points behind the scenes, if that was needed.
  • When you don’t have points, velocity can’t be used a reason, excuse, or driver for not changing the Sprint duration when it makes sense to change it.
  • One potential issue, the “Chickens”.  Sponsors/management wanting to know what will be delivered when, wanting to see a burndown.  The Product Owner would have to handle this.


“No backlog sizing at all” approach:

  • Consider whether or not the backlog even needs to be sized, maybe it doesn’t.
  • The team goes off of experience/feeling to determine what they can do each Sprint.
  • Thinking you can be predictive in sizing can be dangerous.
  • As a Coach/ScrumMaster, don’t bring up sizing to the team and wait to see if there is noise as a result.

Comments (0)

You don't have permission to comment on this page.