User Stories Applied

www.whizlabs.com | ©Copyright 2013

Module 3:

User Stories Applied


Table of Contents

Module 3: User Stories Applied .................................................................................................................... 3

User Story .................................................................................................................................................. 3

Writing Good stories ................................................................................................................................. 7

Splitting User stories and other guidelines ............................................................................................... 9

Use case vs. User Story ........................................................................................................................... 10

Key ideas of user story ............................................................................................................................ 10

Gathering Requirements / user stories................................................................................................... 11

User Modelling and Persona ................................................................................................................... 12

Personas .............................................................................................................................................. 13

Extreme Characters ............................................................................................................................. 13

Responsibility of developer & customer in user role modelling ......................................................... 13

Module Revision ..................................................................................................................................... 14

Case Study ........................................................................................................................................... 14


Module 3: User Stories Applied

User Story User story is one of the widely used tool/practice across agile methodologies. Let’s understand the user story and concepts behind it, in the form of conversation between Tom and Harry.

Tom is quite proud about his lengthy, fleshy requirement specs while Harry is more into agile methods recommending user stories.

Tom Harry Tom Harry Tom Harry Tom Harry

Your team should really learn from this team, see how nicely they write a detailed requirements spec. Okay, how does that help? Aren’t there any changes later on? I have heard arguments with customer and customer saying something like “I know what I said but that was 6 months back”. Customer can change their mind, based on increased understanding. These issues are there but isn’t that customer’s job to do enough thinking before confirming the requirements, rather than changing the mind later on. Yes, customer should try to do enough research and try to provide sufficient details. However, there is a practical limit for customer to visualize everything up front. They might get better ideas and have more understanding after seeing initial versions of software. Think this way, while giving a paining contract for your house/office, how many people know exactly what colour/shades should be applied where, what kind of designs should be present. Even in practical life, we do, lot of trial and error. We change our mind after seeing initial outputs. Hmm. You have a point. While you spend lot of time and effort in preparing detailed requirement documents, aren’t there any issues of wrong interpretation or false assumptions? Actually there are issues quite often and we run into long debates of what was written and with what intent. That’s the whole point. Customer rarely gets what they want. Vast amount of time and energy are spent on debating what was written, instead of doing what needs to be done. Build is done based on what is in the spec rather than what the customer want. Other part of trouble with big bulky requirement specifications is, stakeholders find these quite difficult to read. Some of them are not interested in all requirements but just interested in few areas and these are the people whose inputs could be highly important. We miss out their inputs as they don’t have time & energy to read the whole requirements documentation.


Tom Harry

I tend to agree with all the issues that you have highlighted about up front big detailed requirement gathering exercise but highlighting the problems is easy. Tell me if you have a better way. In Agile rather than a big requirement document, we create product backlog. The agile product backlog is a prioritized features list, containing short descriptions of all functionality desired in the product. Just to have everything at one place, there are other items also placed in product backlog which can’t really be classified in functional terms. A typical product back log contains (PBIs – product backlog items):

Features – User Stories (will talk about this in a minute)

Defect Repair – Defects found in Done stories

Technical work – For e.g. Automation of test scripts

Knowledge Acquisition – Prototyping, Modelling, Exploration

Other – Documentation etc

By far, the predominant way for a Scrum team to express features on the agile product backlog is in the form of user stories, which are short, simple descriptions of the desired functionality told from perspective of the user. An example would be, "As a shopper, I can review the items in my shopping cart before checking out so that I can see what I've already selected."

http://www.mountaingoatsoftware.com/topics/user-stories


Tom Harry

This is how a typical backlog look like:

Basically the features on which work needs to be done in immediate future will be more detailed, granular and properly prioritized. Functionality that will be worked on later could be left as Epic i.e. a large user story. Epics are typically low priority requirements – they are low priority that’s why these are left as epics otherwise they would have been broken into multiple small user stories. For e.g. Epic is – “User should be able to manager his/her resume”. Now this may be later broken down into multiple user stories such as:

As a user, I want to be able to edit my resume As a user, I should be able to inactivate resume As a user, I should be able to delete resume ........

Let me also coin another term – Theme, which is nothing but a logical group of stories. For e.g. All stories related to monthly MI; All stories for library Admin function. Typically word feature is used for epic or theme and many times we show a hierarchy that feature contains multiple user stories. This user story sounds like an interesting thing. Tell me more about it. How story look like: - A story contains three parts

1. Title – 3-10 words to distinguish this story form other stories 2. Description 3. Acceptance criteria

The recommended template for description part of user story is: “As a [user role] I want to [goal/desire] so that [reason/benefit]” /* this clause is option

Please note this format is good but it’s not necessary that user story be written this way only.


Front of card

Story No: 172 Dependency on: None Title : Save Prompt While closing Description As a user closing the application, I want to be prompted to save anything that has changed since the last save so that I can preserve useful work and discard erroneous work.

Priority : 4 Estimate: 2

Back of card

Confirmations

1) Change anything and then try to close application. It should prompt for save

2) Try to close application without changing anything, it should NOT prompt this time.

Harry Tom Harry Tom Harry Tom

User stories are composed of three aspects Card, Conversation, and Confirmation:

Card : - A written description of the story used for planning and as a reminder, typically written on index card.

Conversation: conversations about the story that serve to flesh out the details of the story

Confirmation: tests that convey and document details and that can be used to determine when a story is complete

Top Tip – Understanding three C’s of a good story and the fact that user story is a support tool for analysis and estimation rather than detailed requirement, is quite important for ACP exam. Index card? Even if it’s just one small functionality but how can you write complete details of that on small index card? You don’t have to put all the details. User story is a tool to support planning so you just need to have basic details. It’s a reminder to collaborate about the topic of the user story later on. The focus is more on verbal communication between customer and developer rather than written specification. If you understand this basic, there is no hard & fast rule to put user story on index card only. The agile underlying values - collaboration and just-in-time – make user stories a good agile tool. Got what you mean by card & conversation but not so sure about confirmation part. On the back of index card for user story, customer is asked to put success criteria - basically some acceptance tests. The idea here is not to capture each and every test case but to broadly understand the success criteria. Acceptance tests provide basic criteria that can be used to determine if a story is fully implemented. Moreover, these provide additional information about key business rules, which can be used by developers before start of the coding. Who should write the user stories?


Harry Tom Harry

The customer team, rather than the developers, writes the user stories for two key reasons. 1) Customer team is best placed to describe the desired feature. 2) Story must be written in the language of the business, not in technical jargon, so that

the customer team can prioritize the stories for inclusion into iterations and releases.

Stories are initially typically written in story writing work-shop, but stories can be written anytime throughout the project. In practice, many times domain experts or even developers write the stories. They key here is, customer should provide content and own this activity. Sometimes the end users are not available to play role of customer so we have to use user proxies. Typically business analysts or domain experts are used as user proxies. Are there any guidelines for what you call as good user story? Yes there are:

Writing Good stories To create good stories we focus on six attributes. A good story is INVEST (remember this acronym), which means Independent, Negotiable, Valuable, Estimatable, Small, Testable. Let me explain more:

Independent Dependencies in the stories lead to planning & prioritization issues so we should try to create stories as independent as possible. There could be two tricks to resolve dependencies: a) Combine the dependent stories and create slightly large but independent story. b) Do the split in a slightly different way

Negotiable – Stories are not written contracts or baselined requirements, which are hard to change. Stories should contain basic information (as mentioned in suggested template) and other notes about issues to be resolved during conversation. The details can later be negotiated between customer and development team.

Valuable – Story should be valuable for user or purchaser. The details which are very specific to IT processes and technology could be valuable for development team but make no sense for customer/user. Let’s take few examples:-

a) All deliverables should be created using standard templates. b) Team should produce traceability matrix and other deliverables in line with

CMM level 2 c) Use Db2 V9 referential integrity features d) Performance testing needs to be done e) More than 50 users should be able to work in parallel without any performance

issues f) Add a new feature to group individual orders for same client to save courier

cost. a), b),c) and d) are not valuable. These might be useful for development team but these make no sense for customer team. e) and f) are valuable.


Estimatable – The possible reason why story might NOT be estimatable are: o Team lacking technical/domain knowledge o Story being too big.

In case of issue with domain knowledge customer should talk to customer and try to gain domain knowledge. If problem is with technology knowledge, team can conduct a spike i.e. a short time-boxed activity to research/experiment to learn enough to be able to estimate. The story turns into two stories 1) Spike Story to gather information 2) story for real work. For complex stories, it’s good to have spike story in one iteration and complex story in subsequent iteration. A large story should be disaggregated into smaller constituent stories so that these can be estimated more confidently. As explained previously a large user story is called as Epic. Sometimes we deliberately write Epics as placeholder/reminder for further discussion and disaggregation. We can provide a high level estimate, which can change late on.

Small – The story should be of right size, not too big (Epics) or not too small (Just 15-20 mins task). What is ‘right size’ depends on the team, its capability and technology in use. In case of very small stories, consider combining the stories. In case of large stories consider disaggregation i.e. splitting of stories. Epics could be of two types:

o Compound story – Containing multiple small stories o Complex story – Large story which is difficult to divide into small chunks. In this

case, we might need a spike story to gather information.

Testable – Stories must be written so as to be testable. See these: o The screen performance should be good (What is good?) o Software should be easy to use (How do we know what is easy?

In first example if someone says, that all inquiry screens should give the result back within 1 second, that’s something tester can test. Otherwise it’s anyone’s guess to define the good performance.

Top Tip – Remember the acronym INVEST and how that represent key aspects of a good user story.


Tom Harry

Splitting User stories and other guidelines Tell me more about splitting of stories. It sounds like tricky area to me: It is actually tricky and it does require experience in having the right split but let me tell you some basic guidelines for story combining and splitting:

Splitting stories Reasons - There could be multiple reasons for splitting a story such as: - Story is too large to fit into iteration. - Story is small enough to fit into iteration but there isn’t sufficient room to

accommodate this. - A more accurate estimate is required. Bigger size means higher uncertainty and

less precision in estimate.

Splitting Stories – Guidelines - Splitting across data boundaries – If there are too many fields. One story could be

around handling only few basic fields. In subsequent stories, more data fields can be added.

- Splitting on operational boundaries (Slice vertically) – Slice based on functionality rather than going by architecture level layering. Think of this as below three layer cake, wherein your layers are user interface layer, application layer, data layer. Will you slice it vertically or horizontally?

Slicing vertically makes it independent and valuable. A common approach is to split a story along the boundaries of common CRUD operations – Create, Read, Update and Delete.

- Remove Cross cutting concerns – Often it’s good to remove non-functional aspects such as security, error logging and performance etc in separate stories.

- Split stories of mixed priority – If a story contains multiple business rules but these having different priorities, it’s better to split these into small stories.

- Don’t Split a story into tasks

Combining Stories – Guidelines - If stories are too tiny, it’s better to combine these logically into one or more

stories. - Prefer to combine stories which are related and having almost similar priority - Common to combine multiple bug reports

At the same time, let me tell you few other guidelines for user stories:

Closed Story – Story for which success criteria is either clearly mentioned or implicit. It’s desirable to have closed stories.

Include user roles in the stories

Write for one user

Write in active voice

Put constraints on the constraint cards – constraints are typically non-functional requirements.


Tom Harry

Use case vs. User Story Thanks for your advice and detailed explanation. What is the kind of difference and relationship between “Use Case” and “User Story”. A user story is very simple and is written by the customer. The focus is completely on understanding the need for customer and main scenario. It doesn’t handle all possible scenarios of user interaction with system/product. It serves as reminder and starting point for additional discussion with the customer to know the full extent of needs. Use case is typically more complex and is written by the developer in cooperation with the customer. It attempts to be complete, accurate, and handle all possible cases. During development, it's intended to be able to answer any developer questions about customer requirements so that developers may proceed without having to track down the customer. There is no exact 1-to-1 or 1-to-many kind of relationship between these two terms. The exact format and amount of details in use case vary. Agile methodology prefers user story but then there are people who write user cases with less precision so that these are quite close to user stories. Another important difference between use cases and stories is their longevity. Use cases are often permanent artefacts that continue to exist as long as the product is under active development or maintenance. Stories, on the other hand, are not intended to outlive the iteration in which they are added to the software. While it is possible to archive story cards, many teams simply rip them up.

Key ideas of user story Let me summarise the key ideas of user story:

1) User stories are support tools rather than requirements specifications 2) These highlight negotiation / collaboration to happen between the customer and the

team. 3) User stories help in deferring details till later – Just in time detailing 4) They talk problems not solutions 5) They fit nicely as product backlog items


Tom Harry

Gathering Requirements / user stories I now understand what is a user story but how to start the process of gathering requirements and story writing? Agile methodology doesn’t believe in spending long time in requirement gathering. However, that doesn’t mean we should make an effort to gather as much requirements up front as we can even if that means just capturing these at very high level. For example, if user says she might require search facility, make a note – “user needs search facility”. But there is no need to spend lot of time in finding further details such as basis of search and outcome etc. This story will sit as large story or epic which can be disaggregated into small stories later on. The key techniques for gathering stories are:

User Interviews: - Ask open ended questions. Don’t assume that user knows and can explain exactly what they need. Ask follow-up questions; try to show some option to reach to a common point.

Questionnaires:- Questionnaires can be useful if we need to gather information from a large user base. They can help in prioritization of stories for e.g. we may ask out of these features, which one looks most interesting to you. However, this should NOT be the primary technique to gather information because questionnaires can’t ask follow-up questions and may lead to faulty conclusion. If you keep the question objective, it’s hard to know what else users need. If you keep it free-form text, hard to consolidate information.

Observation:- If there is opportunity to see users using actual software, grab it. You may get many ideas about how to improve user experience.

Story Writing workshops:- This is a meeting attended by developers, testers, users, customers and any other parties who can contribute in writing stories. These people brainstorm and try to write as many stories as they can (focus on quantity rather than quality i.e. amount of details in each story). No estimation or priority assignment happens at this stage. Create a parking lot of issues to come back to. Also, think about user roles and personas while writing stories


Tom Harry

User Modelling and Persona Can you elaborate more about user roles?

Many times for same feature there are different types of users. Their needs and interaction with product could be so different that writing story with just one generic role will not make sense. For example, let’s consider a travel web site. Basic case would be to search hotels. However, there could be different user types, just for illustration some of these could be:

a) Business people – Typically looking for hotel with business facilities – typically frequent travellers can spend more.

b) Domestic holiday traveller c) Newly married couple d) Students – typically looking for budget hotels

While each user will come with a different background and try to user the application for different purpose. However, it’s still possible to put all users in broad categories.

The typical steps in identifying and selecting a set of user roles are:

Brain-storm and identify initial user roles – Customer and developers meet and try to identify as many roles as possible.

Organize the initial set – Try to put user roles in broad categories and try to check overlap between various user roles. For e.g. in previous example of travel web site, broader user roles could be a business/corporate traveller, Vacationer, Administrator

Consolidate roles – Try to consolidate and remove roles having too much of overlap in terms of usage, needs etc.

Refine the roles – Identify relationship between various roles and role attributes. The attributes worth considering are:

o User’s general proficiency with computers or electronic devices on which software is supposed to run

o User’s level of proficiency with software being developed o User’s purpose of using software. o User’s level of knowledge of domain. For e.g. if software is for banking

application, domain here means general banking knowledge o Frequency of usage


Tom Harry Tom Harry

Just now you mentioned a term ‘personas’. What does that mean?. Personas Persona is an imaginary representation of a user role. We create persona for key important roles (not for all) as it helps us in understanding the user experience better. Stories become much more expressive when put in terms of a persona. Developers instead of asking “will it be easier to use this feature for a user”, team would ask “Will it be easy for Jim to use this feature”. Add details to the persona such as name, likes and dislikes, job, goals etc. Instead of “programmer looking for job”, it should be “Java programmer currently working for ABC Ltd. Looking for a job in New York”. A photo can also be added. Basically everyone in the team should feel they know the persona. Personas do represent real, stereotyped, composite, and fictional people. They are archetypal (exemplary) descriptions, grounded in reality, goal-oriented, specific, and relevant to generate focus. However, personas are not a replacement for requirements on a project. However, we don’t just make up persona. We have to ensure that enough market and demographic research has been done so that personas really represent the product’s key user base. Generally avoid picking personas who are real users.

Extreme Characters Extreme characters as the name suggest are exaggerated personalities - people who are not typical users of the product for e.g. a priest or housewife using dating website. It is very possible that considering extreme characters will lead to stories which are likely to get missed otherwise. It’s debatable whether it’s worth investing time in thinking about extreme characters and the new stories discovered might never be included in the product. Thanks for the explanation. Can you explain in this whole exercise of user role modelling, what is the role of developer?

Responsibility of developer & customer in user role modelling Developer Responsibilities are:

a) Participating in the process of identifying user roles and personas. b) Responsible for understanding user roles or personals – their similarities and

differences. c) While writing software, keep in mind how software will meet requirements of

different user roles and how these user roles with interact with software. Customer responsibilities are:

a) Looking what could be the possible users and user roles. b) Participating in the process of identifying user roles and personas. c) Ensure software does not focus inappropriately on a subset sub-set of users. d) Ensure that each story should be associated with at least one user role or persona. e) Think how different user roles may prefer the software to behave

Ref: User Stories Applied: For Agile Software Development by Mike Cohn


Module Revision

Case Study

Cricket Mania Ltd is an organization, which sells Cricket books and other goods related to Cricket. They are planning to launch a website to sell the goods online. They would start with Cricket books.

a) Identify key user roles. b) Consolidate and come up with a list of key user roles c) Write persona description for the one most important user role d) Write user stories for a book search feature. e) Write few user stories for gift-buyer role type. f) Add few acceptance tests for administrator role type.

Ans:

This is a hypothetical case study so there is no perfect answer. Following are few examples to help in

understanding the concept:

a) Key roles could be: Novice Player, New player, Gift-buyer, Administrator, Cricket Coach, Cricket

academy, Professional player, Experienced player, Sales & Marketing person

b) After consolidation and narrowing, we might come up with a smaller list for e.g. Novice player

and new player can be a single role; similarly professional player and experienced player could

be a single role.

It’s important to consider various aspects here for e.g. user’s proficiency with computers &

internet, knowledge of cricket etc. A gift buyer could be quite proficient with computers but

don’t have much knowledge of cricket. On the other hand a professional player might have

limited knowledge of computers.

After understanding various aspects, you may come up with final list of roles. For e.g. you may

initially tend to put cricket coach in the same category as professional player but after adding

more role description, you may realizes it’s better to put in cricket academy category

considering that this user role typically buys in bulk.

c) Ron is an experienced player, who has played in under-19 national team. He is 22 year old and

trying hard to be part of national team. He is keen on improving his skills so he practices daily

and often reads cricket books. He is comfortable buying from internet.

d) A user can search for books by author, title or ISBN number.

e) A user can look for top 10 most selling books; A user should be able to see review rating of any

book

User Stories Applied

Education

Transcript of User Stories Applied