CSC/ECE 517 Fall 2012/ch2b 1w70 nl

SaaS - 4.2 - SMART User Stories

Introduction

User stories are the basis for defining the functionality of any given system . They are a short description of the system that capture what the system does and gives the expectation of how the system should behave. When we say User Stories, we don’t define any particular criteria as to how a user story should be written. A user story can be “Customer should have a good UI experience” or “When a customer logs in he/she should be able to see all the technical details of the product he/she has selected, with the reviews, price displayed alongside and an option of ‘Add to Cart’ to go along with it.” Both the user stories described above are correct but one leaves too much for one to assume and the other gives one specific information in terms of display and functionality. The problem with the first user story is it is not restricted to any particular guideline, its just a user story but has no scope and hence can be either very short or very long. The advantage with the second user story is that it has been written based on a given set of goals which can be acronymed as SMART and will be explained below.

SMART User Stories

SMART,in SMART User Stories is a mnemonic for

• S - Specific
• M - Measurable
• A - Achievable
• R - Relevant
• T- Timeboxed

S -Specific/ M - Measurable

The user story should be specific enough to capture the requirements of the user. The user can be the customer who requires the software or the end user who will be using the software. Many times the user stories are vague or ambiguous leading to a lot of loss in time and energy spent in development. User stories can be made specific by using the terms 'Given, When and Then' which describe the user story. The term “Given” specifies the background scenarios. It specifies all the preconditions. “When” specifies the input to the system. “Then” specifies the desired result/s.
Example:[1]

  Given I am at www.google.com
  When I click on the button Gmail
  Then I should be redirected to Gmail.

Each scenario should be testable i.e its progress should be measurable. There should be known good output for every input. Every project needs concrete criteria for measuring progress toward its completion. The reason behind this is that if the scenarios are not measurable, it is not possible to know whether a team is making progress toward successful completion. Measuring progress is supposed to help a team stay on track, reach its target dates, and experience the exhilaration of achievement that spurs it on to continued effort required to reach the ultimate goal.

A - Achievable / T - Timeboxed

Goals should be set in such a way that it is achievable or at least a working model of it is achievable within a single iteration i.e. within a given time period. The reason for this is that Agile methodologies always aim for working models at the end of iteration, it doesn’t necessarily have to be a complete feature but a run-down version of it which is working partially and is able to provide a minimal set of functionality is also accepted. If the feature is such that it may span over multiple iterations then it is a good idea to break it up into subset of stories such that each implemented subset provides a working model of the feature, however small it may be, so that constant progress is made to implement the feature and also a working code is provided at the end of each iteration.

While its a good idea to divide a feature into sub-features and have user stories for each iteration, the question arises of how to decide on the number of user stories for each iteration and the number of iterations that may require for the complete feature to be implemented. This is usually accomplished using velocity which is an estimate of the kind of progress made in the past based on the difficulty of the user stories and the kind of progress that can be made by taking into consideration the difficulty of the user stories that are yet to be implemented.

As features are broken down to sub-features and stories are written for the sub-feature, which is to be completed within the iteration, points should be assigned to each of the stories based on the difficulty level of the story and how fine grained approach for point-assignment does an assigner want. Say for example an assigner wants just a simple approach for point-assignment then he/she can assign from a range of 1-3 (where 1 being easy, 2 being medium and 3 being hard) and if a more fine grained approach is required then the range can be increased to 1-5 or 1-10. Whatever the approach is followed the important thing is to allocate points to each of the stories based on one’s estimate. At the end of each iteration, Velocity is calculated, which is nothing but the total number of points completed per iteration. As Velocity is not just the total of the stories but the total based on the difficulty level of the stories, it acts as an important guiding tool which can be leveraged by anyone to get to know details about the project as is shown below.

Uses of Velocity:

• Velocity can be used to plan future iterations
• It gives an estimate of how much time or iterations would be required to completely implement the feature
• It gives an idea of whether the team is on track as the velocity is expected to remain constant if all other variables are unchanged (other variables such as number of team members or replacement of an experienced team member with a new team member, etc.)
• It can provide an estimate if a change is requested by customers and based on the time required to implement the change and the importance level of the change the decision can be made whether to implement it or not.

Following this approach allows a task to be timeboxed, i.e. limited to a specific duration. It provides a kind of expectation which makes the team-members aware that if something is not working out its time to seek help, split the task, change teams or do anything that will help in the completion of the task.

At the initial phase, the task of assigning points to stories may seem a bit daunting and a bit like second guessing oneself but as the iterations pass on and based on the understanding of the feature and the experience one has in assigning points to user-stories, the estimation will always improve and at the end will be very close to the actual statistics. Also estimates can be changed if one feels an incorrect estimation was done but care should be taken that the variation is not too much.

R- business Relevant

A user story should be of business value, i.e it should generate additional income or protect revenue. The software defined by the user story can increase the value of the product by generating interest among new users and thereby generating potential new customers.A software can also protect revenue by streamlining processes to cut costs. One way of determining the business relevance of a product is by asking the question “why” recursively. This is similar to a problem solving technique called “5 Whys” where questions asked recursively for root cause analysis. The methodology can be extended here to recursively ask why developing a software is of business relevance to that company. It is assumed that after asking multiple times the reason will have some business relevance (for eg “To increase in revenue for the company”) or there is no valid reason justifying the software project.

Example

Let us understand SMART User Stories by taking an example:

  I want an application that shows me the best deals.

There are all sorts of problems with the above user story. It doesn't fit any of the criterion we have set using our SMART User Stories approach. Let’s go over with each of the problems and try to improve our user story step-by-step.

S-Specific / M-Measurable
The above example is anything but specific nor it seems measurable. Well it does say that there needs to be an application that shows the best deals but it doesn't mention to display the best deals from which all places or websites. Also it doesn't mention about what it wants the best deals on. Also as it doesn't mention about the websites it is difficult it to measure the story.

A much better user story would have been:

  I want an application that shows the user the best deals on a particular product, which is entered by the user before beginning 
 the search, from the websites that preselected by the user.

This says specifically on what product the user wants the search on and from which all websites. This is a very specific goal as there is no scope of assumption here. Of course the search results will be based on the specific words the user enters, but that is true for any website. The more specific you are in your search the more fine grained your search will be. Also because of the modified story, now it is easy to measure the story, as we can go through each website and compare prices and check whether the application did indeed return the best deals from various websites.

A-Achievable
Appropriate timelines and deadlines should be set for implementing and testing the application. Suppose the client wants the above application for the Thanksgiving sale and he comes and asks for it during midweek of November, then creating the above story at that time wouldn’t be useful or advisable as the time period is too short for the goal to achieve.

Assuming there is sufficient time for the application to be created and there are say 4 iterations possible. But the above story may not be practical for one iteration, one might need to break it down further to make it workable for 1 iteration as the target is to have a workable code at the end of each iteration. So the story for the particular iteration can be modified as:

  Provide an interface for the user to provide the name of the product and the websites he/she wants to have a search in.

This would be achievable for the first iteration. For the second iteration more functionality may be added:

  Look for the price of the product in all of the websites given by the user and fetch all the results.

This can be further modified in iteration 3 to give the best deal, based on price factor. This can be further modified to modify the result if any free goodies are being provided by any particular website. In this way the goal can be made achievable.

T-Timeboxed
All of the above 4 iterations that we planned should have the deadlines appropriately. If we suppose till one particular date if the team-member responsible for developing one particular functionality is not able to reach the target goal, it might be a good idea for him/her to ask to someone else or for some senior member to help out or to swap teams itself so that someone who has knowledge can work on that and can complete it without affecting the deadlines and making sure that the product is still workable at the end of that particular iteration. This should be followed for all the iterations. This will also allow sufficient time for testing which is a very important part of the application development.

R-Relevant
The story should be relevant so that the desired benefit can be obtained and maximized. Why would the client need it

• Probably because there are many websites which offer different deals and to get a single website which searches all the websites on behalf of the user or at least a subset of the websites would make it much easier for the user
• That will also lead to increase in the clicks the website gets
• Which will subsequently lead to increase in ads
• Which will lead to increase in revenue for the company

Now the above goals are relevant for the application that user wants but it may not be relevant for the Terms and Conditions page or the login page that application may have.

Advantages/Disadvantages of SMART User stories

Advantages of SMART User stories

Lets consider the advantages of SMART User stories by considering each letter of the mnemonic.

• Making a user story specific makes the objectives of the project clear and prevent confusion amongst teams
• Having a well defined input/output relation makes the project measurable/testable for bugs and defects.
• Having a specific user story helps breaking the project down to achievable goals. These goals can be accomplished in single or multiple iterations.
• Asking whether a project is business relevant helps in identifying the maximum potential of the project.
• A timeboxed project helps in monitoring the progress of the project. It is also possible to estimate the velocity of the project using timeboxing.

Disadvantages/Limitations of SMART User Stories

• Some people prefer other kind of mnemonics such as INVEST rather than SMART as they feel that the thing that SMART stands for is not the same for all people. S may stand for Specific for some, Significant for some, Stretching for others, similarly M may be Measurable or Meaningful, likewise each of the alphabet of SMART has different meaning for different people.
• It is important that points assignment to user stories is done by someone experienced enough to understand the features that customers require as well as the complexity and technical details required to implement it successfully otherwise the velocity will be far from what is expected.

Conclusion

SMART User stories are a great way of defining goals as they have parameters on which to base the decision but for some they are not too specific, primarily because each of the letter of the acronym holds different meaning for different people.

References

<references/> SaaS 4.2: SMART User stories
SMART User experience strategy
INVEST in good stories and SMART Tasks
User stories: Its SMART to INVEST

See Also

Information on user stories
Information on SMART tasks
Information on SMART goals
Link for 5 Whys