David Anderson talks about the core of Kanban as an agreement that the team has a capacity; that they can only work on so much at a time; and a limit set around that work. Implicit in Lean work management styles is the right-sizing of work items. Reducing the broad variability in work item sizes is a part of the work that goes into flow and into controlling cycle time.
Typically, in a method like Scrum, a team organizes its work efforts around user stories. The user stories that are worked on during an iteration (or sprint) can be any of a number of sizes. Using the Fibonacci estimation technique the variation in story size can be almost infinite.
User stories are a way to communicate expectations, but they're a less effective way to manage work and improvement because of the amount of variation allowed in user story sizes. You could decompose stories into smaller stories so that they're more manageable, but then you'd risk fragmenting the communication value of stories by breaking them into separate chunks that might not carry as much context as the original larger stories.
User stories can be of variable size because they inherently are of variable size. Let user stories be the size that makes sense for the kind of artifact that user stories are: an artifact intended to communicate context and expectations to the development effort. Use right-sized work items to manage work. Decompose user stories into work items and schedule those work items for development in way that takes both customer priority and technical constraints into consideration.
The work items can certainly be linked back the stories that they are decomposed from, but it's the work items rather than stories that go through the development pipeline.
I've sat through enough all-hands Agile planning and estimation sessions to know that while this practice is useful for bringing a new agile team together, it's often a terribly ineffective way to establish design. It's a good way to socialize design, but there are alternatives that don't imply the wastefulness of traditional Agile planning and estimation. Using design as a team-building exercise can put the design at risk.
In the worst cases, the all-hands planning and estimation that is common to Agile development methods can hurt the team. It's just as likely that adversarial conditions can break out in the team if an expectation is set that suggests that product design and implementation design are egalitarian and democratic within a team that is necessarily staffed by people of varying experience and ability.
Design should be done by those who are most capable of doing design. Story decomposition should be done by the person or people who are best equipped to do that work. This doesn't preclude the socialization of that design to the team and the proving of that design by the team.
Rather than all-hands estimation and planning, design and planning can be done in short, effective sessions with the team's designers. Since designers are decomposing to work items that are intended to be of a similar size, the team no longer estimates work, but reviews the decomposition and seeks clarification and raises concerns. The collective intelligence of the team is still leveraged, but the potential waste and ineffectiveness of traditional Agile planning is avoided.
The planning and estimation activities change from larger-scale chunks of time, effort, and team participation to smaller units of tiered work and cooperation that can be done just-in-time rather than on those specific days of the week when the whole team's attention can be coordinated and directed to a fixed-schedule meeting. Consequently, any all-hands team meetings can be scheduled on an as-needed basis as well, eliminating any waste that comes from institutionalizing all-hands meetings according to a fixed timebox.
With planning, design, and scheduling being done in smaller units on a just-in-time basis, some of the fixed time boxes in the development process aren't needed. Features can be queued for packaging and deployment on an opportunistic basis as well. There may still be some fixed rhythms at-play in the effort - customer demos and major market events, for example - but these synchronization events don't have to leak their scheduling mechanics into aspects of the work that aren't dependent upon or necessarily coupled to those rhythms.
Work items aren't just same-sized, they're also small-sized. The larger the work item, the more variability there is between the estimate of the work and the actual work. We understand larger work items with less certainty than smaller work items. That's because decomposing work into smaller items means that we have to think about the actual units of design and work that go into delivering those bigger features. Because we're trying to achieve flow in pull-based systems, the variability inherent in larger work items is a likely obstruction.
The specific amount of work that defines what "small" is depends on the kind of work, the team, and a handful of factors. And the actual size of "small" will likely change over time. In some cases, it might just be impossible to get all work items to be of similar size. Consider whether the work can be scheduled so that groups of similarly-sized work items can to be done together.
Without leveling, flow will continue to be difficult, and Kanban a Japanese word that has come to mean "story wall".
Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience
Learn more about my work and how I can help you at ampgt.com
