Ways to split big User Stories into smaller ones
Check out my course about Scrum on Udemy for free https://medium.com/agile-pies/scrum-fundamentals-1-5h-course-on-udemy-for-0-limited-offer-279d03e516cd
The word “decomposition” is used in several ways:
- dividing the story into subtasks by type of work — for example, write requirements, design a solution, create a design layout, write code, etc. — or by architectural layers;
- dividing a large story into smaller, independent stories that fit in one sprint.
Decompositions of the first type, of course, are useful to do (by the way, Definition of Done helps with this), but they do NOT help to release increments every iteration or more often.
Why is it necessary that the story fit in 1 sprint?
- Following the Scrum principle of incrementality. Of course, not a blind following — there are many advantages to working with increments, 15 of them are listed here.
- Simple idea — work with the risk of not being on time.
- And you can also decompose even during the sprint, when you realize that you will not have time to complete the task in the current statement.
And now 2x2 types of decomposition and splitting in more detail
- Decomposition by stages of the product creation process
- Decomposition by architecture layers, platforms, components
- Splitting by business process roles and steps
- Splitting by the level of detail with which you implement different parts of the feature
Decomposition by stages of software development process
The first type of decomposition is into functional tasks, into stages of SwD process, software production. It seems natural because employees are used to functional roles. Such a division provokes 1) problems of interaction at the junctions. Moreover, from the incremental delivery and MVP point of view, 2) the internal discarded artifacts are not needed by the client, 2) and implementation of only part of the tasks does not bring value. Therefore, this decomposition does not help to create useful increments.
Decomposition by architecture layers, platforms, components
The second type of decomposition divides a characteristic or function into subtasks according to architectural layers: subsystems, platforms, devices. This division also seems natural, because it reflects the internal technical implementation structure of the product. However, this inner kitchen is not interesting to the client. From the MVP point of view, part of these subtasks can be cut off, postponed and implemented later (these views are marked “Yes” on the right).
Splitting by business process roles and steps
Decomposition into pieces from user’s perspective is called splitting, because you can divide the task in half, implement only one part, and postpone the second to a later date or not do it at all, or slicing, because if you depict the architectural layers in the form of a layered cake, a vertically cut piece will bring little but full value to the client.
Splitting by the level of detail with which you implement different parts of the feature
These viewpoints are better for splitting/slicing user story while still bringing a value to the client. It’s crucial to try to only release what’s really important, and not impose exaggerated restrictions like “it can only be done in one piece”. In many real-life situations this means, rather, “it’s possible to do it in several pieces, but it’s better to do this and that at once.” Guided by the desire to do more in advance (big design up front), programmers tend to design the whole database right away, create all the obvious prospective attributes, reference dictionaries, administration fuctionality, etc. Consider doing the opposite — adhere to the YAGNI principle (you aren’t gonna need it), since honestly you may not need some of the features. Each MVP has to be verified against the the customers needs. The second principle is KISS (keep it sweet and simple) — to release increments frequently, they should be smaller.
All together
The picture below contains all the methods and text with comments. Download and enjoy ;)
