User stories in agile software development

Prepared by: Sandra Svanidzaitė & Eglė Kumpelytė

Agile background for stories

• The Agile Manifesto• Communication• PDCA - Plan, Do, Check, Act• Why, What & How

The Agile ManifestoWe are uncovering better ways of developingsoftware by doing it and helping others do it.

Individuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on

the right, we value the items on the left more.Source: www.agilemanifesto.org

Project Management is all about communication

People who want IT must communicatewith people who can build IT.

Effective communication

PDCA - Plan, Do, Check, Act

Why, What & How

• WHY are we doing this?• Voice of the stakeholder (Stakeholders)• WHAT needs to be done?• Voice of the user (Product Owner, Subject

Matter Expert)• HOW do we build it?• Voice of the developer (Agile Team)

Agile User Stories• Work breakdown structure (WBS) in traditional vs. agile projects • What is a user story?

– Cards - Conversation – Confirmation– INVEST guideline– Story forms/templates– Skill levels regarding user stories of an Individual and Agile Team– Non-functional Requirements gathering

• User Story writing workshops, techniques and concerns– User Role Modeling– Trawling for Requirements– User Proxies– Epics and user story breakdown

• User Stories vs. Use Cases vs. Requirements• Requirements IEEE 830• Product Backlog of User Stories• Tips for Writing Good User Stories• Smelly User Stories

Alternative to Work Breakdown Structure (WBS)

What is a User Story?

• User Stories provide a light-weight approach to managing requirements for a system.

• A short statement of function captured on an index card and/or in a tool.

• The details are figured out in future conversations between the team and the product owner or customers.

• This approach facilitates just in time requirements gathering, analysis and design by the following activities:– Slicing user stories down in release planning– Tasking user stories out in sprint planning– Specifying acceptance test criteria for user stories early in

development

Why User Stories are so Good?

• Understood equally well by everyone• Useful for iteration planning• Great for iterative development• Encourage deferring of details• Support opportunistic design• Emphasize verbal communication

The 3 C's

What is a Story Card?

• Short description of user or customer valued functionality. • The visible part of a story, which is followed by

conversations between the customer and the project team and confirmation of acceptance criteria. – The customer team writes the story cards because they are in

the best position to express the desired features and because they must later be able to work out story details with developers and to prioritize the stories.

– The customer team includes those who ensure that the software will meet the needs of its intended users. This may include testers, product manager, real users and interaction designers.

User Story - INVEST guideline

User Story - INVEST guideline

User Story-INVEST guideline

User Story - INVEST guideline

User Story- INVEST guideline

User Story - INVEST guideline

Story form/template I

As a < role >I want < activity >

so that < business value >

• Role - represents who is performing the action. It should be a single person, not a department. It may be a system if that is what is initiating the activity.

• Activity – represents the action to be performed by the system.• Business Value – represents the value to the business. Why is

this story important?

Story form/template I

• The "role – activity – business value" template is one of the most commonly recommended aids for teams and product owners starting to write user stories.

As a bank customer I want to withdraw money from an ATM

So that I’m not constrained by opening hours or lines at the teller’s

User Story form/template I

"As a < role >, I want < goal/desire > so that <benefit> "

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.

User Story form/template II

"As a < role >, I want < goal/desire > "so that <benefit> can be optional

As a non-administrative user, I want to search for my customers by their first

and last names.

User Story form/template III

"In order to < receive benefit > as a < role >, I want < goal/desire > "

In order commissions would be calculated differently to each agency,

as I accountant I want system to allow me to set up these values

manualy in commisions tab

User Story form/template IV

"As < who > < when > < where >, I want <what> because < why >"

As a accountant who is managing policy commisions,

I want commisions to be calculated, because we need use different rates for different

aggencies

Acceptance/Validation criteria

• like stories it's written in simple language• define the conditions of success/satisfaction• provide clear user story boundaries• remove ambiguity by forcing the team to think

through how a feature or piece of functionality will work from the user’s perspective

• establish the basis for acceptance testing– steps to test the story (given-when-then scenarios)

Acceptance Test form/template The Given-When-Then formula is a template intended to guide the

writing of acceptance tests for a User Story:

(Given) some context(When) some action is carried out

(Then) a particular set of observable consequences should be obtained

Given my bank account is in credit, When I attempt to withdraw an amount less than my

card’s limit,Then the withdrawal should complete without errors or

warnings

Skill levels of Agile Team

An Agile team will benefit if the skills that underpin effective use of user stories are widely distributed among the team. – It is likely that people with background in

"requirements analysis" or with a history in "analyst" roles will have a leg up in acquiring these skills.

Skill Levels of an Agile Team

• Beginners– the team is able to obtain, "just in time", the information

necessary to implement user stories, for instance by having access to the product owner or domain expert

• Intermediates– the team formalizes all activity as work on user stories, each

team member can answer at any moment the question "what user story are you working on at the moment“

• Advanced– at any moment, any member of the team can answer the

question "what is the most important user story in the backlog, and why"

Skill levels of an Individual Contributor• Beginner

– able to illustrate a user story with an example (including user’s goal, existing context, user’s actions and expected outcomes)

• Intermediate– knows or can identify the relevant user roles and populations

and refers to them appropriately in user stories

• Advanced– can assess a user story using the INVEST checklist or an

equivalent, and rephrase or split the user story as necessary

Non-Functional Requirements Do User Stories Really Help?

• Agile teams focus on identifying User Facing Features in the form of User Stories that can form the basis of incremental deliveries.– Business Analysts work closely with stakeholders to

understand what user stories must be satisfied by the product that they are developing.

• A flaw in this approach can be that users don’t mention non-functional requirements (NFRs) and developers don’t push to understand what quality attributes the software should satisfy.

Consider Non-functional Requirements from the Start

Most software systems are in use for many more times longer than they take to build. So you need:

• Start conversations about the operating environment and user expectations early.

• Talk about the quality capabilities of the system, like performance and security, at the start of the project.

• Hold a session with the team to brainstorm risks to consider what are the things that can go wrong once the system is live?

Types of Non-functional Requirements

Basically, non-functional requirements relate to qualities of the system that cut across user facing features, such as availability, efficiency, flexibility, portability, security, performance, reliability, reusability, robustness, scalability, usability. —However, these requirements do affect the

function of the system and it is possible to design tests that these qualities are present.

The difference from functional requirements

• The difference from functional requirements is that these qualities must be present throughout the system rather than delivered in one-shot like a user facing feature. Alternative terms for non-functional

requirements are "constraints", "quality attributes", "quality goals" and "quality of service requirements".

NFRs Can be Grouped Into

• Execution qualities, such as performance and usability, which are observable at run time.

• Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system.

Agile teams need to consider both categories of NFRs so how do we ensure that these don’t get missed?

Who should have take responsibility?

• When asked for user stories, stakeholders often forget to mention the NFR assuming that these will simply be there. Unfortunately, the agile team cannot

telepathically know what the business needs and when pressure seems to be about delivering features consideration of NFRs gets neglected.

Agile Team should Take Responsibility

"Many development teams don't grasp the fact thataccountability for getting the requirements (all therequirements) right falls to them." Dave Nicolette

• An agile team has to take a more proactive role regarding requirements.

– User stories are not simply mini-requirements specifications that are handed over to development fully formed.

– Writing stories on cards is a very interactive process that involves the technical team asking questions about acceptance criteria that includes NFR.

We must take responsibility for flushing out NFRs so first tip for capturing NFR is to actively start looking

for them!

Using Stories for Non-Functional Requirements

As a < user role > I want < goal > so that < business value >

• Some teams like to use this template for everything that they work on including NFR because that's a consistent format. – Shaping NFR into user stories helps people outside the team

understand the benefits better. • This can become a disadvantage, if these requirements may be

seen by business stakeholders as optional or "nice to have". – It’s important to include the "so that" part to make it easy to see why

such NFR stories are important from a business perspective to help ensure that they don’t get de-prioritized simply because they are not understood.

Using Stories for Non-Functional Requirements

• Usually agile teams keep it simple and simply factor NFR into acceptance criteria for affected user stories.

• This effectively makes work on NFR invisible. – The odd thing about doing this is that any stories

which imply significant architecture work have higher estimates than others but because the architectural piece is below the surface it the estimate belongs to whichever story that gets worked on first. This can be difficult to explain to stakeholders.

Using Stories for Non-Functional Requirements

• Another approach is to introduce "technical stories" to cover anything that needs to be built or restructured but is too difficult to explain to business people.

• The developers are trusted to include only those technical stories that make sense often working within an allowance of such stories per iteration.

• The benefit is that these don’t get de-prioritized by business people and yet these stories explicitly appear on the team board and progress on them gets discussed in daily stand-up meetings.

• This approach is often popular for teams working on legacy systems with many complexities that need to be cleaned up and made testable.

• One worry with this approach is that this excludes the business from deciding what the project budget is spent on.

"Try to avoid tech stories. Look hard for a way to transform a tech story into a normal story with measurable business value. That way the

product owner has a better chance to make correct tradeoffs." Henrik Kniberg’s

The beauty of User Stories for Non-Functional Requirements approach

Is that all requirements (functional and non-functional):

Look the sameCan be understood by everyone

Have the same visibility as other storiesThis approach is that normally elaborating

requirements as user stories help a agile team understand user needs better.

Non-functional Requirements examples

• Efficiency: Specifies how well the software utilizes resources (CPU cycles, disk space, memory)

• Flexibility: Increase or extend the functionality of the software after it is deployed, that should be planned from the beginning; it influences choices made during the design, development, testing, and deployment of the system.

• Portability: Portability specifies the ease with which the software can be installed on all necessary platforms.

• Security: Security requirements define the security attributes of the system, restricting access to features or data to certain users and protecting the privacy of data entered into the software.

• Performance: The performance constraints specify the timing characteristics of the software.

• Usability: Ease-of-use requirements address the factors that constitute the capacity of the software to be understood, learned, and used by its intended users.

Non-functional Requirements examples

How do we gather user stories?

Trawling for Requirements

User Proxies

Customer Team

User Role Modeling

User Role Modeling Steps

1. Brainstorm an initial set of user roles2. Organize the Initial Set3. Consolidate Roles4. Refine the Roles

Refine User Roles with Attributes

User Role Example

Where are the Details?

Details added as smaller User Stories

Details as conditions of Satisfaction/ Acceptance Criteria

Types of User Stories

The Backlog Iceberg

Breaking Down Epics

User stories vs. use casesUser Stories Use Cases

• Provide a small-scale and easy-to-use presentation of information. Are generally formulated in the everyday language of the user and contain little detail, thus remaining open to interpretation. They should help the reader understand what the software should accomplish.• Must be accompanied by acceptance testing procedures (acceptance criteria) for clarification of behavior where stories appear ambiguous.

• Describe a sequence of interactions, and may be worded in terms of a formal model. A use case is intended to provide sufficient detail for it to be understood on its own. A use case has been described as “a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system”.May be delivered in a stand-alone document.

Software Requirements Specification IEEE 830

• The Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) has published a set of guidelines on how to write software requirements specifications. This document, known as IEEE Standard 830, was last revised in 1998.

• The IEEE recommendations cover such topics as:– how to organize the requirements specification document; – the role of prototyping; – the characteristics of good requirements; – Recommended way to write functional requirements is “The

system shall…” .

Software Requirements Specification IEEE 830

• IEEE 830–style requirements have sent many projects astray because they focus attention on a checklist of requirements rather than on the users goals. – And lists of requirements don't give the reader the

same overall understanding of a product that user stories do.

• It's very difficult to read a list of requirements without automatically considering solutions in your head as you read.

SRS IEEE 830 examples:

• The system shall allow a company to pay for a job posting with a credit card.

• The system shall accept Visa, MasterCard, and American Express cards.

• The system shall charge the credit card before the job posting is placed on the site.

• The system shall give the user a unique confirmation number.

Software Requirements Specification IEEE 830

• Documenting a system's requirements to this level is tedious, error-prone, and very time-consuming.– Additionally, a requirements document written in this way is,

quite frankly, boring to read. – Just because something is boring to read is not sufficient reason

to abandon it as a technique; however, if you're dealing with 300 pages of requirements like this (and that would only be a medium-sized system), you have to assume that it's not going to be read thoroughly by everyone who needs to read it. Readers will either skim or skip sections out of boredom.

Additionally, a document written at this level will frequently make it impossible for a reader to

grasp the big picture.

Software Requirements Specification IEEE 830

• A powerful and important feedback loop occurs when users first see the software being built for them. When users see the software, they come up with new ideas and change their minds about old ideas.

• When changes are requested to the software contemplated in a requirements specification, we've become accustomed to calling it a “change of scope.” – This type of thinking is incorrect for two reasons. First, it implies that

the software was at some point sufficiently well-known for its scope to have been considered fully defined. • It doesn't matter how much effort is put into upfront thinking about

requirements; we've learned that users will have different (and better) opinions once they see the software.

– Second, this type of thinking reinforces the belief that software is complete when it fulfills a list of requirements, rather than when it fulfills the goals of the intended user.

Differences Between User Stories and SRS IEEE 830

The cost of each requirement is not made visible until all the requirements are written.

• With stories, an estimate is associated with each story immediately. – The typical SRS IEEE 830 scenario is that one or more analysts spends

a lot of time writing a lengthy requirements document.– This document is then handed to the programmers, who tell the

analysts that the project will take longer as had hoped for. In this case, time was wasted writing the document that the team won't have time to develop, and more time will be wasted as the developers, analysts, and customer iterate over which functionality can be developed in time.

Tips for Writing Good Stories

Smelly user Stories

Literature• Mike Cohn, "User Stories Applied", 2004, Addison Wesley,

ISBN 0-321-20568-5• http://www.powershow.com/view/143a1f-MzFjO/User_Stories_Applied_For

_Agile_Software_Development_by_Mike_Cohn_powerpoint_ppt_presentation

• http://www.slideshare.net/dneighbors/effective-user-stories-10265381• http://www.slideshare.net/dimka5/agile-stories-estimating-and-planning• http://broadcast.oreilly.com/2010/02/nonfunctional-requirements-how.html • http://guide.agilealliance.org/guide/stories.html• http://www.methodsandtools.com/archive/archive.php?id=113• http://broadcast.oreilly.com/2010/02/nonfunctional-requirements-how.html• http://en.wikipedia.org/wiki/Non-functional_requirement• http://en.wikipedia.org/wiki/User_story• http://guide.agilealliance.org/guide/stories.html• http://www.mountaingoatsoftware.com/articles/advantages-of-user-stories-f

or-requirements

Material For Further Reading

• http://www.agilemodeling.com/artifacts/userStory.htm

• http://www.mountaingoatsoftware.com/articles/advantages-of-user-stories-for-requirements

• http://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories

• http://vimeo.com/43601248• http://www.math.uaa.alaska.edu/~afkjm/cs40

1/IEEE830.pdf