October 6, 2020

Agile User Story Splitting by Bronze-Plated vs Gold-Plated

Post by: Rachael Wilterdink

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”.


Relevant Insights

Are You Falling into the Cloud Conversation Gap?

Most conversations about migrating services to the cloud focus on migration of application workloads and data. The vision is often...

How Aggregation Tables Improve Performance for Power BI Reports

In this blog, Marcus Radue, Solution Architect, offers high-level guidance in the advantages of aggregation tables in Power BI. For a...

Getting Started with Azure DevOps – Views

Like most Microsoft products, there are many ways to look at or perform the same activities. Azure DevOps is no...