User Story Splitting – Manual vs Automated
Another option for splitting stories is by breaking out manual processes vs automated. If a process can be handled manually, even temporarily, it can enable teams to quickly provide business value. The automation of the process can be done later.
I recently worked on a project that required an update of the app’s data three times a year. The data doesn’t change in the interim, but when it does change, it’s extremely important that it’s updated right away. In this case, we had to manually do a data update because of a deadline. The plan was always to automate the process, but given the business need to have the data updated right away, it had to be done manually.
The story split for this might look like:
Questions to ask:
- Will a manual process work to start with?
- How often will the manual process need to be performed? (And how long will it take?)
- Will you save a significant amount of time and/or money by automating the process?
In some cases, it will make sense to go the automation route. But in other cases, the cost to build the automation may not be worth the time and effort to build (if the manual process is minimal).
User Story Splitting – Zero > One > Many
This concept is borrowed from hardware architects. It’s simplest to start with an empty set, then one, then many. This technique is useful when you can have multiple instances of something. Following along with my fake recipe app, here is an example of what stories split by zero, one, and many could look:
This technique really seems like a no-brainer to me, and I don’t think it requires much more description.
Questions to ask:
- What will it look like if you have no instances of something?
- What would just one instance look like?
- What would multiple instances look like?
It’s easier to start with getting one instance right before moving on to more.
References:
https://www.slideshare.net/kentjmcdonald/21-story-splitting-patterns-49940134
https://xp123.com/articles/twenty-ways-to-split-stories/
