Skip to main content

Story decomposition

Last post 02:09 am May 25, 2016 by Bartek Kobylecki
3 replies
05:05 pm May 23, 2016

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?

11:22 pm May 23, 2016

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

09:40 am May 24, 2016

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

02:09 am May 25, 2016

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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.