User Story breakdown question
-
I have a scenario where a command can be sent to a device, and the device will shift through states to until it reaches the destination state.
We already have errors for state changes that aren't commanded.
We already have errors for error states.This is notifying the user of each state shift.
The user also wants to inhibit notification of each state shift.
I personally feel my team has a fundamental problem with making user stories too large for convenience of programming larger chunks uninterrupted.
I recommneded breaking it down into four stories.
- Each state change during a command will generate a notification.
- User can configure inhibits per state.
And then, this set would be applied to two different value types that accept state-based commands.
- A bit (on off)
- A variable size (state a - n)
However, the person reviewing is shoving it back into one story.
Does anyone agree with me, or am I going overboard?
-
The rule we use when breaking down user stories is "can each card be picked up independently by different developers without conflicting with each other?". If the answer is no, then you're fine. If the answer is yes, then you've got what should be a task under the story.
-
But, what if you have a giant feature that each usable portion of the feature is dependent on the previous one?
Do you just end up with a giant task that's impossible to break up?
-
It's tricky to say, because each case is different.
We usually try to put some ground work in place that will allow the developers to implement their own bits without worrying about others.
For example, we will generate stubs or interfaces to program against. For UI we will create stub templates and components, that can then be fleshed out. It's very rare that we need to do this though.
You need to do what will work in your own situation. Perhaps you need to work on how you divide up the work you are going to do on each sprint. We use an approach called "vertical slicing", each sprint we will focus on an individual feature that adds some value to a product, but is part of a bigger picture gradually progressing towards a larger feature.
A guy from Dominoes pizza told me a great example of how they did it. (INB4 vertical "slicing" pizza pun).
Their end goal was to make a 1 click ordering thing for their mobile app, basically you press a button that says "give me pizza" and pizza shows up at your door. They approached this by tackling it in small chunks over each sprint.
-
The first slice allowed the customer to save their payment details. This immediately added some useful functionality to their app, and would also be required by 1 click ordering.
-
The second slice allowed the customer to save a "favourite basket" of items, e.g. "meat feast pizza, diet coke and chocolate fudge cake". Again this was immediately useful in the app, but was also required for the feature.
-
The third slice allowed the customer to set their default delivery address.
-
The fourth slice added the button that said "give me pizza".
You see, by using vertical slicing, you can gradually tackle a feature that would normally be too large for one sprint, over several sprints.
-
-
Right, and I'm saying that generating the events is one slice, then inhibit config is a separate slice.
You can't work on inhibit config until the base feature is in place, just like you can't add a "give me pizza" button immediately either.
I see them as separate stories, but maybe not. Maybe they'd just be frustrated by the nuisance notifications that they can't inhibit.
-
Right, and I'm saying that generating the events is one slice, then inhibit config is a separate slice.
You can't work on inhibit config until the base feature is in place
The point of them being different slices is you can't have more than 1 slice in a sprint, so the dependency relationship isn't a problem.
-
A guy from Dominoes pizza told me a great example of how they did it.
I order Dominos too much. I remember when each of those features was introduced.
