Story decomposition
I am trying to get a better sense of how far stories need to be decomposed and to aid in this I am going to use a very simple example.
Imagine you are building a very simple login component for a website. You have decided that it can be decomposed into 3 stories...
1. A login component that first only allows people with credentials to login
2. An enhancement that depends on story (1) and shows any error messages if the user's credentials are not validated correctly
3. Again an enhancement that allows a user to reset their password if they have forgotten it.
You have decided that together these 3 stories offer a marketable feature though you also realise that there may be many other stories to come.
If we accept that stories should comply with the INVEST mnemonic (search Google if this confuses you) we may consider 2 critical points:
1. That we accept that we need to offer VALUE if we deliver stories
2. Because of the independence of stories we may not know if other stories will also be delivered
... then my question is this...
Should we always deliver stories 1 & 2 together? Without story 2, there is nothing that really can go live and offer real value to a user is there. Has the decomposition gone 1 step too far?
> Should we always deliver stories 1 & 2 together?
> Without story 2, there is nothing that really can go
> live and offer real value to a user is there.
Yes. You should never release an increment that is without value, and each increment delivered must be potentially releasable.
> Has the decomposition gone 1 step too far?
No, because an increment may consist of multiple Product Backlog Items, each of which can be a User Story. As regards the INVEST criteria, each story:
- should be valuable in so far as it contributes to the potentially releasable value of the increment
- should be independent in so far as it can meet the Definition of Done without other stories being brought into progress at the same time.
There can be advantages in releasing increments that are as small as a story but Scrum does not require this. There only needs to be an increment which is provided no later than the end of each Sprint.
+1 @ Ian.
Something else to keep in mind Mike.
A major benefit of story decomposition is the ability to provide smaller items of functionality quicker, and receive faster feedback from the business/end user than if functionality were "batched" together in a larger story that made more sense from an implementation standpoint.
While actual marketplace delivery of items 1 and 2 together makes sense, there is "value" in being able to develop the solution for item #1 and vet such solution with the business/PO/customer.
There is a sentence I heard from my friend:
Don't split (or decompose) stories. Simplify them.
In my opinion your stories 1 and 2 are simple, not decomposed.