How you break down work matters!
Building a software development platforms is a large and complex task. The intent of breaking down your work is to turn this complex task into a collection of smaller, more manageable, easier to estimate, components.
However, the breakdown technique you choose will have an impact on the success of your team's ability to deliver value quickly!
Broadly speaking there are two approaches to breaking work down
Horizontal Breakdown
The first approach involves breaking stories down by the kind of work to be done, or by the layers that are involved. Examples include UI, design, database, front end, back end, testing and items are created for each on the backlog. There are a number of challenges with horizontal breakdown, effectively it does not result in working demonstrable software and it encourages silo thinking along the lines of, I have done my task, so it is complete, without any consideration of usability from a user perspective and if it means the user need. The other challenge is that it introduces bottlenecks, developers must wait for UI, test must wait for developers. Also, it means that prioritization is done by order of tasks, rather than by value to the user.
Vertical Breakdown
The second approach is called vertical breakdown, i.e. thin slicing. The intent is to break the solution into thin slices of functionality that will give us working, demonstrable software quickly.
An example would be:
As a customer, i can pay for my order
This could be further decomposed into:
As a customer, pay by wire transfer
As a customer, pay by BPAY
As a customer, pay by credit card
As a customer, pay by cash
The benefit of this approach, is that we can achieve user value quicker if we break it into 4 stories and if we run into time delay issues and we only have enough time to do 2 of the 4 stories, i still have working software, whereas if i took the horizontal approach, we would have to delay working software and feedback
Vertical Breakdown Strategies
Break work down by workflow steps, pay for order above is a good example of this
Break work down by business rules
Break work down by happy and unhappy flow
Break work down by data types/parameters
Benefits of vertical slicing to teams
Make value explicit in their backlog
Encourage more discussions about value
Tend not to accidentally build low value changes
Get value sooner
Get early, higher quality feedback
See constraints and product inventory more easily and respond accordingly
Get more predictable in delivering value[Working software being the primary measure of progress]
Transparency on %age complete using features built/not built
Strategies for vertical breaking work down
Break work down by workflow steps, pay for order above is a good example of this
Break work down by business rules
Break work down by happy and unhappy flow
Break work down by data types/parameters
Best Practice - Breaking Work Down
Define Program Increment [Intent, Description, Problem , metrics, users, features, ranked]
Program Increment Backlog - 1 backlog master for full traceability for all teams
Backlog is broken down into features and user stories and is D.E.E.P
Create cross functional team(s) who will work together to deliver feature/stories
Map features/stories to sprints, align cross functional teams, remove as many dependencies as possible and get team to deliver a thin slice of working software in the sprint
