The Ideal Bite Size of the User Story!


burger

Most of us use the User Stories in our daily work. Let´s do a quick recap of the definition:

A User Story is the Just Enough description of the User Needs.

In other words, it describes the Who, What and the Why part of the task to be done (Source: Wikipedia).

Now, let’s face these two Big questions….

>>       Why are the User stories important?

>>       Why do we need to have Small yet Effective User stories?

The transition from Waterfall to Agile methodologies is never easy. The Waterfall approach consists of these documents to analyze the User needs: BRD (Business Requirement Documents), FRSs (Functional Requirement Specifications), SRS (Software Requirement Specifications), PRDs (Product Requirement Documents), etc. After the initial agreements, the development starts.

In Scrum, the most important artifact to map the User needs is the User Story.

However, sometimes, the User Story is too big or too small or too abstract or never-ending. This often lands the teams in difficult situations. So, it is very crucial to Identify the Ideal Bite Size  — to identify the ideal size of our User Stories, yet keeping these Effective!

Before going further, let´s address this question: How a Good User story look like? (Scrum 101)

In order to answer this question, let’s do a quick recap of INVEST / 3 Cs model of Stories:

a) INVEST: This model says that a Good User Story should have the following characteristics:

                     I – Independent (It should be independent of the other user stories)

                    N – Negotiable (It should be negotiable / not a mandate for the  team)

                    V – Viable (It should carry Business Reason/value)

                    E – Estimable (It should be estimable)

                    S – Small (It should be small)

                T – Testable (It should be Testable)

b) 3 Cs: It consists of 3 basic (and important) things about the User Stories:

Card – Each Story should be “logged in Writing” on a Card. This diminishes the volatile-memory syndrome and everyone sees the same description of the user needs.

Conversations – Conversations should be done throughout: from the Pre-Planning to the delivery stage between: PO and Stakeholders, PO and the Team, among the developers, between the developers and testers, et al. The User story should not sound like a mandate from the PO or any Product person.

Confirmation – After the phase of Conversations, the entire team including the PO should agree to the Scope of the User Story with few directions like Definition of Done, KPIs, User Acceptance Tests, etc.

After going through the basic definitions of User Stories, now, let’s move to the slicing techniques:

a.    MoSCoW Method

This term has no relation with the name of the City ‘Moscow’. It differentiates between the actual needs and the delighters of the Stakeholders.

Here, it means:

M – Must Have (Urgent and Important)

It is the subset of requirements which forms the Showstopper – without which the Sprint / Iteration / Release / Timebox fails. This underlines the MVP (Minimum Viable Product) philosophy.

S – Should Have (Not Urgent but Important)

These requirements need to be done but these can wait till the Next Sprint. If the teams get free early, they can take the tasks from this subset. These requirements can be displayed as “Stretch Goals” in the Sprint Backlog.

C – Could Have (Delighters)

These should ‘Only’ be done if ‘Must Have’ and ‘Should Have’ have been completed and there are no burning issues (read: Bugs) on the plate.

W – Won’t Have (Scoping the Sprint)

These requirements lie outside the box (scope) of the team and these should not be done. Often, teams do not use this subset, however it is very important to define the Maxima Scope of the Product.

This technique is normally used to Prioritize the User needs. However, it is equally important for Slicing the stories as a piece of requirements should not land in multiple quadrants /subsets. If the piece of requirements lands in multiple quadrants / subsets, we need to slice the same into multiple user stories so that every user story lands in one and only one quadrant. Otherwise, the concept of Done or not Done becomes a Never-resolving-mystery for the PO and for the team.

b.    CYNEFIN Framework – Measure of disorder

The Cynefin framework was developed by Welsh Scholar Dave Snowden. It gives a direction to measure the Complexity / Disorder of the Situation (requirements in our case) and suggest the best way to identify the solution. Basically, there are 5 domains of this framework:

The First one is Obvious (earlier: it was Simple). As the name suggests, the Cause and the Effect in this Situation is quite Obvious and Simple (obviously). Here the recommended solution is quite Obvious and there is practically no need to create a New solution. Hence, the Best Practice is followed.

The Second one is Disorder (the center one). If this situation is reached, forget the requirements: no matter what you will do, it will fail. So, you need to ‘Renovate’ the entire process.

The third one is Complicated (the top right). In this situation, you need to Analyze to identify the problem. Once you identify the Cause and Effect relation, then the Good Practice is recommended.

The fourth one is Complex (the top left). In this situation, the Cause can only be identified in the Past (Retrospect) and not in Present / Future. Hence, you need to Probe to find the root cause of the problem and then act. It might work or it might not! So, you need to Adapt accordingly and change your actions accordingly. Hence, the Emergent Practice is recommended.

The fifth one is Chaotic (the bottom left). There is no relationship between the cause and the effect in this case. Here, we need to Act, Sense and Respond by following the Novel Practice.

Like MoSCoW technique: every piece of requirement should be sliced in a way that each lands in one and only one section of Cynefin framework.

c.     Dividing the Stories into Workflow steps

When the stories have workflow steps, these can easily be broken down into Workflow steps. It helps to focus, takes less effort and receives fewer bugs.

Let’s consider the following example:

As a user, I want to pay my Cable Bill from my phone so that I can pay fast.

The user wants to pay the Cable bill using his phone.  It might sound easy, however, it can be broken down into simpler workflow steps (User stories) – each delivering the business value:

As a user, I want to link my Cable account with my phone number so that I need not enter my personal information on every payment.

As a user, I want to link my Credit Card with my phone so that I need not enter my Credit card information on every payment and I can pay using the credit card.

As a user, I want to enable SMS alerts on my phone about the pending bill so that I do not miss any cable bill.

In case, something does not work, the root cause can be easily identified for the smaller Workflow steps.

d.     Create Stories for Happy Path first

Normally, when we start creating the scenarios — we tend to answer the concerns about all the scenarios! These discussions are not required at that time — these can be done later on when the requirements get mature. It might happen that the requirements change and these ‘sad / bad’ situations will not happen at all!

So, it is recommended to create stories for the Happy Path first and get enough clarity on the same. We can still create stories for the other paths if and only if we are quite sure that these need to be done immediately. However, the stories of the Happy and the Bad Paths should not intersect.

Also, the Risk Assessment is one of the Product Owner’s babies!

For example: Product Owner can give a nod of adding 2 New features with 50% Risk-Probability or adding 1 New Feature with 20% Risk-Probability.

e.     Keeping UI simpler

We cannot create the Perfect software overnight.

Indeed, we can never create the Perfect software. I will tell you how…!

If we invest a lot of time in making the Software ‘Perfect’, then, the definition of the Perfection (scope) changes and the software remains ‘imperfect’. Hence, we need to build the software in small iterations to reach to the goals. This includes the creation/use of simpler UI like Prototypes, wireframes, mockups, etc. These should be the simplest in approach/implementation and should be done on Paper, whiteboards, using software tools, etc. We can add / improve the cosmetics later on (as & when required).

f.      Improve Performance in iterations

Do not expect the performance to be achieved over-night, instead improve the same in small iterations (different environments, off-peak times, off-peak locations, et al). This way: the complete picture (bird’s eye view) of the requirements is not broken and it lets you to change the plan as well if something does not work as planned. For example:

As a manager, I want to get 100percent uptime of this website to get maximum users >>(100 percent of the cities).

This one can be broken into Performance-iterations as below:

As a manager, I want to get 100percent uptime of this website in 200 cities with the web traffic of 20,000 (or less) hits per day (Zone D) >>(25 percent of the cities).

As a manager, I want to get 100percent uptime of this website in 200 cities with the web traffic of 20,001 – 30,000 hits per day (Zone C) >>(25 percent of the cities).

As a manager, I want to get 100percent uptime of this website in 200 cities with the web traffic of 30,001 – 40,000 hits per day (Zone B) >>(25 percent of the cities).

As a manager, I want to get 100percent uptime of this website in 200 cities with the web traffic of 40,001 (or more) hits per day (Zone A) >>(25 percent of the cities).

This way, the performance of this website will be increased in small iterations incrementally.

g.     Starting with Minimal Data

If a User story processes multiple data types or options, then we should bifurcate the user stories with minimal data/options, e.g.:

As a user, I want to purchase the Music CDs based on genre, artist, album and year on XYZ.com

Technical background: Let’s assume that the genre, artist, album and years are present in different databases or as different tables in the same database. Hence, the linkage of the front end with the backend (database) of each of the attribute is required.

In this case, it is easy to break the story by minimizing the data/options by breaking the story like:

As a user, I want to purchase the Music CDs based on genre on XYZ.com

As a user, I want to purchase the Music CDs based on artist on XYZ.com

As a user, I want to purchase the Music CDs based on album on XYZ.com

As a user, I want to purchase the Music CDs based on year on XYZ.com

The front-end can show all the options (creating separate landing pages for the non-functional options) or only one depending upon the Product Strategy.

h.     Confining within Acceptance Criteria/test cases

Most of the times, the Scope of the User Story changes. Then, a tough battle is fought among PO, QA and the Devs to understand if XYZ requirement is a New Requirement or a Bug. Acceptance Criteria/test case solves this issue. Once we write the Acceptance Criteria/test case(s), it acts as a Check-list and the entire team has the “Single” Definition of the User Story.  It leads to the division of  “abstract” or a “large” user story into multiple — Actionable — small User stories.

As a Call center manager, I want to assign calls to my employees.

1. If the employee is on available mode, new calls can be assigned to him.

2. If the employee is already on a call, new calls cannot be assigned to him.

3. If the employee is on available mode, he can take the break.

4. If the employee is on break mode, the calls cannot be assigned to him.

This is the example of using the Acceptance criteria/test cases as a way to break the stories.

i.      Divide by User Personas

Consider this case:  If you are a Rich patient, then what do you desire in a good hospital:  good ambiance, air-conditioned room, WiFi, television, well-dressed medical staff, good cafeteria and of-course good medical treatment. He is okay to pay more for such additional amenities as these make him happy and he expects these to be a part of the overall package.

However, if you are a Poor patient you will need: Free or cheap but Good medical treatment.  He is least bothered about the extra-amenities that the Rich patient desires!

This situation underlines the importance of the User Personas.  Every User sees the System in a different way.

We should divide the User Stories depending on the User Personas who are actually the Actual Users.

For example:

As a rich patient, I need good ambiance in the hospital so that it makes me happy!

As a poor patient, I need free/cheap medical service in the hospital so that I can stay well without spending / spending less money!

In this case, the system (Hospital) is completely different for these 2 personas.  Similarly, we need to adapt the requirements (User stories in this case) to match the needs of the Users and we should never mix user stories about different User Personas of the system.

j.      SPIKE for Research Stories

What happens when we need to work on a story and we do not know the scope clearly? Should we say: No to such stories? Probably not!

In these cases, we can create Spike Stories. In these Spikes, we can investigate the scope and the dependencies and then sum our conclusions ‘Before’ working on the actual stories.

Normally, people do not Estimate the Spikes (like story points) or give 100 or 0 story points.

Alternatively, you can include the effort exerted by the persons working on the Spike in the team’s velocity. The concept is simple: the investigations done in the Spike do not deliver any Value to the user directly, so Product people do not recommend these to be counted. When the actual work is done, the XYZ points will be counted in the velocity.  Either way — it is your call!

Two important points to note here:

    j.1. We need to time-box the Spikes. Otherwise, people will keep on researching without delivering any actual value.

    j.2. All the Stories cannot be Spikes at the same time. In fact, Spikes should be delimited by a XYZ percentage of the total story points to be delivered in the sprint. Here the number XYZ is decided by Product Owner: primarily by looking at the Business Priorities, Team Capacity, Risk Contingency, etc.

k.     Horizontal Vs. Vertical Slicing

Let’s use the classical example of cutting a cake. If we cut the cake horizontally, then each piece will contain one layer but will miss the flavor of the entire cake. Hence, the cake should be cut Vertically. Similarly, if the user stories are sliced vertically, these will carry ‘actual’ value for the user. On the Contrary, if these are sliced horizontally, the stories will be divided among technologies like SQL, Oracle, .Net, Design, etc and these sub-parts do not carry any value for the user.

For example, let’s consider the story: “To Test the Story #123 in QA environment”.  The problem with this “story” is that it is a “QA task” but not a “Story” as Quality is expected of all the delivered requirements so QA/testing cannot be different story.

Another example is “To Deploy the Story#123 in Staging Environment”.  Giving the same reason, QA/Development/Deployment, et al can be the different stages of a User Story, however, these cannot be different User Stories — as for the user – it is the same piece of requirements.

l.      Split by Operations (CRUD)

Few of the stories include the basic operations viz. Create, Read, Update and Delete (CRUD). Hence, we can easily break down the stories in these operations, e.g.:

As a user, I want to manage my shopping cart so that I can purchase the right product.

This can be broken into the following User stories:

As a user, I want to add products in my shopping cart so that I can purchase the same.

As a user, I want to delete products from my shopping cart so that I can remove the wrongly chosen ones from the same.

As a user, I can update the shopping cart with the newly added products so that I can purchase the right products.

m.   Split by Platforms

This can be applied to a User story which is to be developed for multiple platforms like Android, iOS, Windows 8, etc. In this case, it can be split by Platforms. The benefit in this approach is that the story can Fail in one or more platforms but it is highly unlikely that it will fail in All the Platforms. Hence, at least the user story will work for the Actual user of the requisite Platform. Also, it enables to write better code, receive fewer bugs and solve bugs effectively.

On the closing note, I can safely assume that the write-up will help you in slicing the User Stories in real-life situations using the above-mentioned techniques. If you use any other technique as well, please share the same. Also, I am happy to hear the feedback from you about this article.

==

Speaker’s Bio:

I love coaching People, Teams and Organizations to high levels of performance in an Agile environment and I am a Curious Learner. I would be happy to connect with you. Please drop an email or leave a comment: I will get back to you! Thanks!

http://lnkd.in/deRY9R8

https://twitter.com/gpzee84

==

Further Readings:

http://techblog.holidaycheck.com/brilliant-ways-to-slice-user-stories/

http://www.agileforall.com/2009/10/patterns-for-splitting-user-stories/

http://www.deltamatrix.com/horizontal-and-vertical-user-stories-slicing-the-cake

http://cognitive-edge.com

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s