Simplest Possible Solution vs Complicated (but better) Solution
Let’s say you have a feature that you’re developing, and there’s a field necessary to capture a person’s date of birth. The ideal solution would be to have a fancy date picker where the user could quickly pick their birthdate. But in the first pass – is this necessary? Could you get by with just a text box for the user to manually enter the information?
I recently ran into this exact issue. The original requirement for an app I was working on was to include a slider bar with handlebars on each end to allow a user to tap to pick a maximum and minimum number for filtering. However, implementing that functionality would be too difficult (and would take too long), so the Product Owner decided that keeping it simpler was the better solution (for now).
Instead of our slick sliders, we had boring text boxes so the user could manually enter their min/max numbers. There is still a story in the product backlog to revisit that later; maybe the slider will eventually be added if the Product Owner deems it worthy of the investment.
Generic User Interface vs Fancy User Interface
User interface is another area we can look at splitting stories by. Maybe the UI just needs to function to start out with, and making it “pretty” can come later – the real value of the feature will be that it functions, not that it looks good.
But if the product will eventually be public-facing, and could impact your brand reputation, then you might want to come back and slap some pretty paint on it before releasing to public.
Direct System Update vs User Interface
What about whether you even need a UI to do something? Maybe you have some data that occasionally needs to be updated in your app, but you could simply place an updated file in a directory and a job could be scheduled to ingest and update the data. That would negate the need for a whole separate user interface to perform the same function.
Would it be a better user experience to have a UI? Yes, probably. But how many people would it truly impact, and would those development resources be better spent on something of higher value to more people?
Manual vs Automatic
Another example is manual processes vs automatic processes. What if you need to do a manual update three times a year, but it would take hundreds of hours to program the same functionality to happen automatically? It seems like it would take a long, long time to get any return on that investment. But if the update needed to happen every week, and it took you a whole day to do it, then that might be more of an argument in favor of automating the process.
Questions to Ask:
- Can you start with something super simple, and add complexity later?
- Can you get away with something less refined to start with?
- Can you make updates right at the source, rather than having a pretty interface to make changes?
- Can you begin by using manual processes, and hold off automation until later?
- Do you need a bicycle, or do you want a Ferrari?
It’s sometimes easy to skip ahead to what you think your best long-term solution will be, but what if it’s not? By building “just enough” to be able to release and get feedback, you’ll figure out if you really need the gold version or if bronze is “good enough”.
Resources:
http://www.its-all-design.com/how-to-split-user-stories/
