Decomposing requirements, be they user stories, features, or what ever you use in your process, is inherently a design activity. Division of labor follows the division of software modules, and the division of software modules also follows the division of labor. These design activities have to be done in consideration of each other, likely by the same people and at the same time.
The design should be communicated to the team, and at the very least, to the members of a team who might be tasked with the work, but it isn't necessary to have the whole team involved in creating the design. The best designers should be involved in doing the design work. This should go without saying, but some of the interpretations of "self-organizing team" can contribute to obscuring the obvious: individuals on teams do indeed have strengths, and some are stronger than others.
Communicating design and expectations is a great side effect of all-hands planning and estimation, but it can create poorer designs that are normalized to the average skill on the team while the team learns how to design software. Becoming a competent software designer takes many years of work and the uncanny circumstances that create the precursors of design awareness that, when complimented with experience, creates the talented and mature abstractionists, analysts, implementers, and engineers who lead design efforts. Planning and estimation and teaching and design do share some common ground, but teaching design and growing designers should be an explicit goal with specific work, rather than a magical side effect.
Decomposition, task breakdown, and scheduling are all aspects of design. When we communicate design to the people doing the implementation, we're setting expectations for their work. When we set expectations for people, we (hopefully) activate their critical minds. They inevitably cross-check a work plan and inevitably cross-check the design as they learn about the plan. That's not exactly the same thing as the design-by-committee exercises that are too frequently the result of consensus estimation design, where decomposition is often done as part of whole team sessions that are concerned with dialing in agreements on story points.
Designers front-load the design, bringing their experience and aptitude for design to bear, and provide structure for the ensuing conversations. The tension between the design and the cross-checking can lead to new insights. It can lead to changes in the scheduling of the work and it can lead to changes in the design, but it's not a consensus-based free-for-all that leads to the mediocratization of design. The front-loaded design done by competent designers produces a more balanced equation, especially when they are also designing the work.
This isn't Big Design Up Front or phased-based SDLC though. Designing the work simply means that there's necessary front-loading involved in producing software. Front-loading doesn't preclude inspecting and adapting, responding to change, or emergent design.
The balance between good work that can be continually built upon, work that creates lower standards of productivity, and work that can be managed to expectations hinges on more than good software design. Software development productivity lives at the intersection between well-designed software and well-designed software work. Agile estimation is a good start down the road to manageable software development. Designing the work closes the gap between the beginnings of manageable work, and work that can be managed.
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
