TOOLBOX | PART V | APPENDIX - bdemirjian/apbr2 GitHub Wiki

Anti-Patterns

The purpose of this section is to help teams identify behaviors that can be used to diagnose issues in how the team is working and adjust their behavior to make improvements. Each anti-pattern listed below includes a description, why it is not ideal and how to remedy the issue.

Team doesn't understand the value of the work they are doing

If much of the team feels that it isn't clear what value their work is providing customers or the business, then itโ€™s likely the product owner did not properly describe the value of the feature, epic or story. The product owner should make it a point to communicate to the team the value of a body of a work via a user story, use case or opportunity assessment. (see section "The Path To Ready")

Team spends a lot of time re-writing stories

If your team finds itself constantly re-writing stories for work, then it is likely that they were not part of the original story generation. This can result from the Product Owner trying to "get ahead" by pre-writing stories or from painful planning activities where teams try to pre-write and pre-groom many stories in an attempt to become more predictable. Both simply end up wasting peoples times.

  • If your Product Owner is trying to pre-write stories, suggest that rather than writing stories they focus on creating an epic (or placeholder story) that answers questions related to the business problem and the value to the business (see section "The Path to Ready"). Then organize a story mapping session to break the work into spikes and stories.

  • If you are entering granular stories as part of a planning activity, stop it. Stories created too far in advance become obsolete quickly and break the principle of Just In Time Delivery. The team should be able to plan and provide planning estimates without breaking functionality into granular stories.

Team not pulling in highest priority work

If the team is not pulling in the highest priority work, this could be because the backlog is not in priority order.

If the backlog is not in priority order, refer to the section regarding backlog management for some help in getting your backlog back into shape.

Work rolls over from sprint to sprint

If your team finds itself in a situation where stories are not being completed and are constantly rolling over into the next sprint, they could be experiencing any of the following issues

  • The stories moving from sprint to sprint are too large.

    • When creating and grooming stories, consider giving teams a maximum size. Examples:

      • Stories pointed over a 13 must be broken down further
      • All stories must be able to be completed in under a week
  • The team is committing too much work to the sprint

  • Team members are pulling in new work into the sprint before helping complete existing commitments

Constant back and forth between XD and Engineering

If work frequently goes back and forth between designers and engineers, it may point to a behavior where engineering is not being included early enough in the design process. Designs should include buy in from both product and engineering and they should be included as early as possible in the process. Please refer to the team working patterns section for more help.