Loading presentation...
Prezi is an interactive zooming presentation

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

User stories

No description
by

Agustin Yagüe

on 6 October 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of User stories

A different approach for requirements
User stories
What are User stories?
Independent
Should be as independent as possible
Negotiable
A story IS an invitation to a conversation
Valuable
If a story does not have value it should not be done.
Estimable
A story has to be able to be estimated or sized so it can be properly prioritized
Small
Stories are small chunks of work that should be done on one iteration
Testable
Every story needs to be testable in order to be “done"
INVEST model
They describe the user story
They are defined by PO
Each card contains:
Title
Description (pasive voice)
Business value
Effort (in Story Points)
Priority
Completed in
Inception meeting (First features of the first release)
The backlog grooming (Stories for the next sprint)
Cards
Card example
How to slice it?
Splitting User Stories
Stories are like Icebergs
The Three C's
User stories
The big picture
By Agustín Yagüe
2016
They are a lightweight substitute for specifying software requirements
They are the container that primarily carries the value stream to the user
They represent the use of the system from functionality
Users identified by:

Roles


Persona (HCI Technique)
The Product Owner describes the expected behavior of the user story
Conversation explains how user stories work from the perspective of the user.
They are focused on user interaction.
Conversations are used to identify tasks needed to develop user stories
Conversation
Conversation
Confirmation
Acceptance criteria 1
Given

the booking form
When
I select 0 tickets
and
I press the "Book" button
Then

I receive the message "
Nothing to Book
"
Acceptance criteria 2
Given

the booking form and the performance is fully-booked
When

I select 10 tickets

and
I press the "Book" button
Then

I receive the message "
Not available tickets for that session
"
Given the form to book tickets, first I want to get a scrollable list of theaters with performances. When I select one theater, a list with the scheduled performances is shown as a list. After selecting a session, a seating map is displayed. When I click on a specific seat it changes its color. Finally when I press the "Booking" button, a booking code is assigned and seats are reserved until the payment
Two ways to write tasks
Technical approach
Tasks are focused on identify technical activities
Tasks mix engineering activities and functionality
Example:
Create database
Create GUI
Validate fields
Write tests
Integrate user story
Functional approach
Tasks are focused on identify steps based on functionality
Tasks do not represent engineering activities
Engineering activities underlie each task
Example:
Load list of theaters
List performances for a theater
Select/Unselect seat
Enable Booking button
Generate booking code
Reserve seats
There are some identified patterns
Workflow Steps
Identify specific steps that a user takes to accomplish a specific workflow and then implement the workflow in incremental stages.
US1
Workflow
US1-1
Workflow
Step1
US1-2
Workflow
Step2
US1-3
Workflow
Step 3
Business Rule Variations
At first glance, some stories seem fairly simple. However, sometimes the business rules are more complex or extensive than the first glance revealed. In this case, it might be useful to break the story into several stories to handle the business rule complexity
US1
Business
Rules
US1-1
Business
Rule 1
US1-2
Business
Rule 2
US1-3
Business
Rule 3
Major Effort
Sometimes a story can be split into several parts where most of the effort will go towards implementing the first one. In the example shown below, processing infrastructure should be built to support the first story;adding more functionality should be relatively trivial later on.
US1
Complex
Story
US1-1
Basic
solution
US1-2
More
functionality
US1-3
More
functionality
Simple/Complex
When the team is discussing a story, and the story seems to be getting larger and larger. Stop and ask “what’s the simplest that can possibly work?” Capture that simple version as its own story, and then break out all the variations and complexities into their own stories.
US1
Complex
Story
US1-1
Simple
solution
US1-2
Special
Case 1
US1-3
Special
Case 2
Variations in Data
Data variations and data sources are another source of scope and complexity. Consider adding stories just in- time after building the simplest version.
US1
Complex
Story
US1-1
Data
type1
US1-2
Data
type 2
US1-3
Data
type 3
Data Entry Methods
Sometimes complexity is in the user interface rather than the functionality itself. In that case, split the story to build it with the simplest possible UI and then build the richer UI later.
US1
Complex
Story
US1-1
Simple
solution
US1-2
Special
Case 1
US1-3
Special
Case 2
US1
Complex
Story
US1-1
Base
solution
US1-2
Add 1st
-ility
US1-3
Add 2nd
-ility
US1
Complex
Story
US1-1
Simple
solution
US1-2
Special
Case 1
US1-3
Special
Case 2
Defer System Qualities
Sometimes, the initial implementation isn’t all that hard and the major part of the effort is in making it fast – or reliable – or more precise – or more scalable. However, the team can learn a lot from the base implementation and it should have some value to a user, who wouldn’t otherwise be able to do it all. In this case, break the story into successive “ilities”.
US1
Manage
Story
US1-1
Story
Create
US1-2
Story
Read
US1-3
Story
Update
Operations
Words like manage or control are a giveaway that the story covers multiple operations, which can offer a natural way to split the story.
Typical example: Create Read Update Delete (CRUD)
US1-4
Story
Delete
Break Out a Spike
Spikes are a special type of story that is used to drive out risk and uncertainty in a user story or other project facet.
Spikes may be used for a number of reasons:
1. The team may not have knowledge of a new domain, and spikes may be used for basic
research to familiarize the team with a new technology or domain.
2. The story may be too big to be estimated appropriately, and the team may use a spike to
analyze the implied behavior, so they can split the story into estimable pieces.
3. The story may contain significant technical risk, and the team may have to do some
research or prototyping to gain confidence in a technological approach that will allow
them to commit the user story to some future timebox.
4. The story may contain significant functional risk, in that while the intent of the story may
be understood, it’s not clear how to the system needs to interact with the user to achieve
the benefit implied.
It represents the conditions of satisfaction to consider when the story is done
It represents the Acceptance Test
They are proposed by Product the Owner
Template to write confirmation:

Given
context
When

actions carried out / events happened
Then
results obtained
Cucumber
Concordion
FIT/Fitnesse
Good user stories should follow the INVEST model
As a

Role
I want

Functionality
So that

Business value
Template:
https://prezi.com/jdlcbrg7gsq7/agile-estimation-and-prioritization/
Full transcript