17spm_L13
User Stories
SPM 2017 © Ron Poet Lecture 13 1
Introduction
Introduction
� User Stories is an approach to developing software that meets the
users’ requirements.
� They are part of an iterative approach with short iterations of between
one week and one month.
� Their use discourages the production of a lot of paperwork.
SPM 2017 © Ron Poet Lecture 13 2
� Their use discourages the production of a lot of paperwork.
o The main deliverable is the software, which is constantly added to.
� Most well known exponent is Mike Cohn – “User Stories Applied for
Agile Software”.
A User Story
� A small task that a user might want to undertake.
o A user can search for a job.
o A company can post job openings.
� When first conceived, user stories can vary greatly in size.
SPM 2017 © Ron Poet Lecture 13 3
o Only stories of the ‘right size’ reach the development stage.
� Stories that are too large are called epics.
o Epics are broken down into smaller stories for development.
User Stories and Use Cases
� Use Cases contain several scenarios.
o The happy day scenario, the main purpose of the use case.
o Secondary scenarios, usually when things go wrong.
� A user story corresponds to a single scenario.
SPM 2017 © Ron Poet Lecture 13 4
� The happy day scenario is the first user story associated with a ‘use
case’.
� Stories for secondary scenarios are typically added later.
o Placeholders may be added as ‘conversations’ on the main story.
� The design for the full set of scenarios gradually develops over time.
The Story Card
� The favoured way of documenting a user story is on a single index
card.
o This prevents too much documentation.
� The front of the card contains the story name and a short description
of the user story.
SPM 2017 © Ron Poet Lecture 13 5
of the user story.
� It also contains conversations between the developers about the story.
� The back of the card contains a series of tests.
o If all the tests work then the story has been completed.
� It is a test-driven approach.
A User Story
� The story name is a reminder to talk about this aspect.
� The conversations provide special cases, without much detail.
� The tests capture exceptions and provide an acceptance test for the
story.
SPM 2017 © Ron Poet Lecture 13 6
� Details are deferred until they are needed.
Guidance for Good Stories
� Closed stories, finish with a meaningful goal.
� Focus on near goals.
� Keep the user interface out of the code for as long as possible.
o The user interface typically involves several user stories.
SPM 2017 © Ron Poet Lecture 13 7
o
Features of Good Stories
� Independent of other stories to avoid confusion.
� Negotiable, a reminder to talk later.
� Valuable to users or customers but not developers.
� Estimable.
SPM 2017 © Ron Poet Lecture 13 8
� Small but not too small. The right size to be able to make good
estimates.
� Testable. If a story can’t be tested, how do we know when we are
finished?
Estimable
� Some times it is difficult to estimate the size of a story.
� This could be caused by a lack of understanding of the issues involved.
� This is often resolved by scheduling a spike: an experiment to learn
more about the issues.
SPM 2017 © Ron Poet Lecture 13 9
o This is similar to an experimental prototype in other
methodologies.
� Very small stories, such as bug fixes can be combined into a single
story just for efficiency.
o It is easier to estimate the time for a group of bug fixes.
Epics
� An epic is a large user story with little detail.
� Further study is needed to split it into several more manageable stories.
� This work can be deferred.
o One of the aims of the process is to avoid making all the analysis
SPM 2017 © Ron Poet Lecture 13 10
o
and design decisions at the start of the project.
� The collection of user stories made at the start of the project is not
fixed for the rest of the project.
o User stories can be added as the project progresses.
Splitting Epics
� Some epics are compound.
o They are easy to split into smaller self-contained parts.
o Split into two simpler stories that both go from start to finish, but
in simpler ways.
SPM 2017 © Ron Poet Lecture 13 11
� Others are intrinsically complex and a way of splitting them into
smaller independent stories is not obvious.
� Usually a spike will provide more understanding and reduce the
complexity of the epic.
� The spike will be a specialised user story completed in one iteration,
with the stories from the epic split over subsequent iterations.
� Stories can be split during coding.
o Often the first time a problem is noticed.
Backlogs
� The collection of all stories, including epics, is called the project
backlog.
� Typically all the cards are pinned to a board in the development team
office.
� Stories that have been assigned to an iteration form the iteration � Stories that have been assigned to an iteration form the iteration
backlog.
o Cards on the board are either in an iteration or have yet to be
assigned to an interation.
SPM 2017 © Ron Poet Lecture 13 12
User Story Effort
� The amount of effort required to complete a user story is measured in
story points.
� It is up to the project to define a story point.
� A common definition of a story point is one ideal day.
SPM 2017 © Ron Poet Lecture 13 13
� An ideal day measures what can be achieved if the whole day was
spent working on the project.
� In practice, people can achieve 2 or 3 ideal days per week.
� The other time is spent on email, meetings etc.
Estimating each User Story
� The developers meet to estimate the length of each story.
� Each developer secretly writes down an independent estimate of the
number of story points required.
� They are revealed and the two developers with the longest and shortest
estimates explain their reasoning.
SPM 2017 © Ron Poet Lecture 13 14
estimates explain their reasoning.
� Each developer then makes a second estimate.
� This process continues until the estimates converge.
� Typical lengths of stories is 1 – 4 story points.
� Should not be overly precise.
o Use just ½, 1, 2, 4, 8 and not 3 or 5.
� Developers quickly get experience on how long various types of story
actually take.
User Roles
� User roles are similar to actors in UML.
� The main purpose of a user roles is to generate user stories.
o Also true for actors.
� Look at the application from the point of view of user roles.
SPM 2017 © Ron Poet Lecture 13 15
o What things would they want to do.
o Each one generates a user story.
� Sometimes it is useful to have non-human system roles.
o If another computer system will interact with our system then it
will generate stories.
Describing User Roles
� Each user roles is recorded on an index card.
o The name of the role.
o Frequency of use.
o Domain expertise.
SPM 2017 © Ron Poet Lecture 13 16
o
o Computer expertise.
o Software expertise.
o Goals.
Finding User Roles
� Brainstorm an initial set of user roles.
o Each member of the team thinks of user roles independently and
writes cards for them.
� Organise the initial set by overlapping cards where roles overlap.
SPM 2017 © Ron Poet Lecture 13 17
� Consolidate roles, removing duplicates.
� Refine roles by adding details.
Personas
� It is sometimes useful to invent a single person, or several persons, to
represent a user role.
� They are given names, dates of birth etc.
� This often makes it easier to guess some details when implementing a
user story using role modelling.
SPM 2017 © Ron Poet Lecture 13 18
user story using role modelling.
� Extreme personas can also be interesting.
User Proxies
� Sometimes real users are not available but some other person from the
organisation is.
o They can provide inaccurate date.
� User’s manager. May not know what is really needed to get the job
done.
SPM 2017 © Ron Poet Lecture 13 19
done.
� The development manager is a bad choice because of conflicting goals.
o They may want to speed up development or get a cheap version.
o They may want to use inappropriate technology.
Proxy Users (2)
� Sales people can be good if they lead you to real users.
� Marketing people don’t really know what users want.
� Business analysts may prefer to think about a problem and solve it
themselves, rather than research what users really need.
SPM 2017 © Ron Poet Lecture 13 20
Gathering Stories
� Focus on the more immediate stories and write epics for the more
distant ones.
� User interviews.
� Questionnaires.
SPM 2017 © Ron Poet Lecture 13 21
� Observation.
� User role modelling. Useful when the right mix of users is not
available.
� Story writing workshops using low fidelity prototypes.
o Paper drawings of the user interface and screens.
Acceptance Tests
� Write the tests before coding.
� Use an automated process for testing because the same tests will have
to be run repeatedly.
� Agile methods involve repeatedly adding to existing code.
SPM 2017 © Ron Poet Lecture 13 22
o This involves regular refactoring.
� Testing processes.
o FIT: Ward Cunningham.
o FitNesse: Bob and Micah Martin.
Non Functional Requirements
� Not everything can be expressed as a user story. These are non-
functional requirements.
� They are written on a story card as if they were stories.
o Short description.
SPM 2017 © Ron Poet Lecture 13 23
o Conversations.
o Ways to test them.
� These cards are labelled as constraints.