Is my "Personal Contact Information" theme broken down properly?

Question

We're currently working on a project and debating with others how best to break the project down. Below I'm just providing titles, not writing the full User Stories, to make it quicker to read through.

• Project: My Account (Online)
  • Theme: Personal Contact Information
    • Theme Epics:
      1. Contact Address
      2. Contact Numbers
         • Epic 2 Stories:
           1. View and update Home Telephone number, plus validate the format.
           2. View and update Mobile number, plus validate the format.

Now, there is some debate over whether Contact Numbers really needs to broken down into two separate stories. My opinion is that there is a need. We may launch with just the capture of Home Telephone number, then Mobile number at a later date.

The second debate is that I would break these down further to have a separate Story for the validation, example:

1. Validation of the Mobile number

So, the argument may be that there is no value to the customer of this story. However, there is some value, in that it is to help the customer to ensure they have entered a valid mobile number i.e. UK starts with 07 or +447. Aside from that, my reason for having separate stories for validation is that we could launch without validation of the mobile number, although it would be nice to have.

Breaking things down into smaller chunks makes it all more manageable: easier to progress, easier to track progress, and the progress is much more visible. Plus it makes it easier to iterate.

Additionally, I would be even tempted to breakdown the View and Update of the Mobile number into separate stories because, again, we could just go live with View only. I feel this reflects building incrementally, much like Spotify suggest with their example of Skateboard, Scooter, Bicycle, Motorbike, Car.

Is my approach valid?

Answer 1

TL;DR

Your approach appears valid, but only you and your team can determine whether it's optimal for your current process. Decomposition is about finding the optimum story size for your team's process; while smaller stories help maintain flow, some stories can be so small that the size of the work unit is swamped by the process overhead each story entails.

Evaluating the Level of Decomposition

Is my "Personal Contact Information" theme broken down properly?

There is no canonical answer to this question, since the necessary granularity of user stories (or traditional work breakdown packages, for that matter) will depend a great deal on things like:

• Your team's Definition of Done.
• The complexity of the problem domain.
• The length of your iterations.
• The maturity of your team.
• Whether it makes sense for your team to decompose stories further.

As an example, consider whether making view, update, and validation steps separate stories makes sense for the project. This will depend a lot on:

1. Your framework.

   Some frameworks make it trivial to treat all three deliverables as a single unit of work, while others don't. Your mileage will therefore vary.

2. Your dependencies.

   If the stories can be done independently, then you can certainly make them separate stories if that adds value for the project. However, treating interdependent task-level items as separate user stories is often a project smell.

3. The delineation between a story and a task within your project.

   Treating a bunch of sub-tasks as multiple user stories simply adds process overhead. As an additional consideration, a story should rarely (if ever) be prescriptive, and task-level items are generally prescriptive by nature. Try to keep your stories as granular as possible while ensuring that even the smallest story remains above the task level.

4. Your unit of work.

   As a shining example, while there's nothing inherently wrong with breaking the stories into smaller stories that remain above the task level, on a Rails project with a mature team I might make a single story out of "support validated cell phone numbers on the contact page." To me, that unit of work seems relatively small and idempotent. Again, your mileage may vary depending on context and capabilities.

Validity of Your Current Approach

Is my approach valid?

Your approach certainly seems valid in the abstract, but whether it's useful within the context of your particular project is something on your team can determine. The underlying question is whether the additional level of detail helps or hinders the team. If a story generally follows the INVEST principles and fits within a single iteration, then further decomposition may simply add overhead or complexity to the planning process.

There are two things of special note to consider here:

1. The "V" for value in INVEST doesn't always have to be value for the end user.

   Value can be for the project, rather than just and end user. As long as there's a clearly-identified "value consumer" for the story, and so long as the Product Owner (or comparable stakeholder in your framework) finds value in the story, then that's sufficient for "V".

2. Decomposing stories is a trade-off.

   As you say, smaller stories are easier to manage in a variety of ways, and are generally more "agile." However, all stories carry a fixed amount of process overhead, so there's a balance to be struck between keeping the story as small as practicable without making it so small that it adds unnecessary bookkeeping or framework overhead. This balancing act will require different trade-offs for each project, team, and story, so your team will have to find its own optimum.

Answer 2

I'm going to disagree with the other two answers here and say: no, your approach is not valid. Consider the simple use case of a contact that doesn't have a home phone, just a mobile one. They are going to be frustrated by a system that rejects their only phone as having an invalid home phone number.

Instead I'd suggest you think in terms of breaking the stories down into:

1. View and update primary number
2. Validate primary number against a simple validation set, eg that mobile numbers start 07 or +447 (with warning if it doesn't appear valid)
3. Validate primary number against full validation (not sure if only UK national numbers are needed here, or world-wild, but eg 076xxx numbers are not valid mobile numbers in the UK).
4. View and update a secondary number
5. Validate a secondary number

Story 1 would be the highest priority, but depending on your achived velocity against expected, you could eg drop Story 2 completely and go straight to 3, implement story 5 after 1 etc, thus giving you flexibility in what's delivered in each release.

Answer 3

Looks good to me.

I would probably break the stories down like so:

1. View Mobile Number
2. View Home Number
3. Update Mobile Number
4. Update Home Number

then the PO/business can balance their relative priority.

As for validation of phone numbers there is a decision to be made on whether they are stories in their own right or additional acceptance criteria on the two update stories.

I don't think there is a right or wrong answer to that. It depends on the value to the business of the validation and the cost of cleaning up any invalid phone numbers if and when the validation stories are eventually implemented.

Personally I'd make the phone number validation part of the acceptance criteria on the assumption that it is a very small task and it will avoid waste (invalid data that will have a cost to clean up in the future)