David Fox, State Farm Insurance Cos., and the right others ...
Problem:
- 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.