Agile’s fundamental principle of incremental development is core to the benefit opportunities available to teams. In practice, this principle is often overwhelmed with pressure from the market, leadership and team dynamics to DELIVER. The pressure is never qualified. You never hear ‘Deliver value with high quality and in a sustainable way. That pressure sets up teams to fall into many different agile anti-pattern traps. Here is where Product Managers and Product Owners can step up and help their teams avoid these traps by understanding them and dealing with them.
One anti-pattern trap to understand is that there are way TOO many large user stories. These never complete within an iteration. This enslave teams. This is one type of anti-pattern story.
User Stories are meant to be light-weight carriers of solution intent. When small, user stories are easier to complete within an iteration which they should be.
Despite earnest attempts in backlog refinement to decompose stories teams struggle with developing small user stories. There can be many reasons for this. Often these reasons are interrelated, and even experienced teams struggle to address the root causes. You may have user stories that are well written to form, have good acceptance criteria and supporting conversational information but are for all intent and purposes are Epics, which are by definition too large.
An Epic is functionally dense. An Epic, also referred to as a feature, is anticipated to take more than one iteration or sprint to complete. When work on an Epic is inadvertently scheduled for an iteration the size is assumed acceptable. As work starts the team soon realizes the challenge. It is not working on a single user story. Instead, they have jigsaw puzzle with potentially many user stories. Decomposition of an Epic in the middle of an iteration creates delay. Epic decomposition needs to occur BEFORE it is worked on.
Another anti-pattern type of user story is the pseudo-code user story. You may have user stories that are more programming specification that have too much how and not enough who, what and why. This takes real-time reactive and adaptive coding solutioning out of the hands of developers. Invariably when the developers actually start working on the story, presumptions are found wanting, more questions arise that have to be addressed either within the team or with the product owner. All this creates delay. Both type of User Stories need restructuring before they are worked on in active iterations or sprints.
It is the Product Manager and Product Owner who are responsible to make sure their teams don’t fall into these traps. They can do that by applying two simple scope shaping principles.
All user stories describe SCOPE whether a programming spec type or epic. Scope that must be delivered. And high-performing agile teams do deliver scope even when dealing with these type of stories. A characteristic of high performing teams is intimate knowledge of itself. This includes an intimate understanding of their assigned scope, their own capacity limits and the balance between the two. They KNOW their constraints even if not articulated or documented or quantified in an equation. They (almost) NEVER take more work, or commit, to scope they cannot deliver within an iteration. How do they do that?
They learn. Because high-performing agile teams were once low-performing agile teams. They mastered the dynamics of the backlog refinement ceremony. They executed the needed pre-cursor meetings of discovery and/or analysis. They intuitively learned to reduce the size of user stories to FIT them and their capacity limits. Like a kitchen strainer allows liquid to drain but holds back larger solids, the team has learned to let smaller user stories reach their team and iteration backlogs.
All well and good but how does a team get there? Sounds more art than science. Well, it’s both. The Art is about being sensitive to the emerging knowledge and the science is about respecting the clock and the calendar.
This art and science balance is applied through use of the Constraining Boundaries Principles or proverbs. They are stated as follows:
When teams work with (create, refine, decompose) user stories (scope) they must keep in mind two boundary conditions that respect the clock and calendar:
- No Feature (epic) should take longer than 2 iterations to complete.
- No User Story should take longer than 5 days to complete and be accepted. 3 days is best practice.
These are simple proverbs that work. Why?
Because when the team begins to work with their scope, their natural understanding of the business domain, technology limitations, financial conditions and their own abilities emerge. That emerging knowledge is powerful. It needs to be directed to unlock the benefit of the incremental development principle. Constraining boundaries provide guardrails as emerging knowledge energy flows. Furthermore, these constraining boundaries are subtle proxies for a team’s natural capacity limit. There is only SO MUCH a single team can do in 2 weeks. They know it. They feel it.
When Product Managers and Product Owners help teams keep these principles in mind during scope creation and Backlog Refinement, these constraining boundaries help teams reduce scope (user story) size and complexity naturally. The SCOPE itself will bump up against the constraints. As teams observe and understand these guardrail impacts, they will shape the stories accordingly to fit the clock and calendar.
You might also be interested in: Fundamental Principles of Requirements Engineering
These proverbs are simple to learn for any team. Implementing them will be difficult. Here the Product Manager and Product Owner can lead and serve. They can encourage the team to reduce user story size by acting as gentle gatekeepers. They can help with the interpretive size reduction process even when it gets messy. The first few times around will be a struggle, but persistence will lead to rewards.
As scope for an iteration is reduced to reality, unrealistic fears of “the team is slowing down!” or “the team is underperforming” will arise. Here the Product Manager and Product Owner can elevate the team and encourage leadership to TRUST the team and let them do the work.
Application and perseverance of these simple proverbs can help agile teams become free from the bondage of overcommitment. Over time you will see it is working. How? Fewer and fewer stories will escape from the current iteration into the next and that means scope and capacity are being balanced artfully by the team.
Meet the Author
Tony Timbol is an agile coach, trainer, and consultant with a 35-year history in technology and software development. Currently serving as an Enterprise Agile Coach for a large healthcare insurance provider, Tony teaches and coaches agile best practice principles, the SAFE framework specializing in the Product Owner role, and agile requirements authoring processes.
Find him over at Be Agile Ready.