User StoriesAgile Software Development

Topics

ObjectivesBrief History – MotivationProcess OverviewA User StoryWriting StoriesManagingDevelopment PracticesThe JourneySummary

Objectives

Discuss agile software development practices, with 30% focus on user stories

Brief History - Motivation

Brief History - Motivation

*g SoftwareNumber of Feature

m– number of iterationt- iteration size g – Measure of usefulness, goodness

*m t where t is proportional to *n RequirementComplexity + *b DesignComplexity

+ Code + *y Feedback

Process Overview

I-MeetCustomer + Dev TeamPrioritize stories, estimate velocity

R-MeetCustomer + Dev TeamPrioritize stories, estimate

Daily StandupCustomer + Dev TeamStory Workshop,

Conversations, etcCustomer Team

A User Story

3 parts Planning placeholder & reminder Notes from conversations Tests

Not system’s point of view

User Story – Planning Placeholder & Reminder

Taskboard & Release/Sprint Planning(VersionOne*)

*Mingle is a trademark of Thoughtworks*VersionOne is a trademark of VersionOne

Card Walls & Release/Sprint Planning(Mingle*)

Notes from conversations

E.g.Customer Service can search for orders so that they can quickly access the customer’s order when customer calls in to make changes to the delivery address

Notes : Zie says always show customer name, order reference number, order date.

Tests

Conveys to developers additional information

Developers get an idea if they are done

Treat as specification

Tests – Specification/Test Collaboration Framework

Questions

What are the 3 parts of a user story?

Writing Stories

Form and functionAttributes INVESTTrawlingStories Smell

Writing User Stories - Form and function

The role, goal and motivation.<role’s> wants to do <goal>

because <motivation>

Example : As an account holder, I want to transfer funds between two of my accounts so that I can maximize the performance of my savings and avoid any fees associated with overdrafts and minimum balance rules.

Writing User Stories - INVEST E.g. of non-independent story :

Customer can pay for basket items using iPay88 payment gatewayCustomer can pay for basket items using WorldPay payment gateway

Possible Solutions: Combine both If combining both is too large – split out the base

work: ▪ Customer can pay with one type of payment gateway▪ Customer can pay with two additional types of

payment gateway

Writing User Stories – INVEST Too much detail such that the extra details is

associated to extra precision – always negotiable

Valuable to Users User easily understands : Test with Credit Card, Debit

Card and Cheque User cannot understand : Test that Payment table

contains the authorization id for credit card Acceptable to indicate non-functional requirements

like : This feature is expected to be used by 200 users concurrently and at any one time 200 payment records can be shown quickly, may be in 2s.

Writing User Stories - INVEST

Estimatable 3 reasons for wrong estimation▪ Story is too big▪ Developers lack domain knowledge▪ Developers lack technical knowledge

Large stories/epic simply a large value if not the focus other break it

Split to Experiment within a specific time with the objectives of

estimation - Spikes Story to do the actual work

Writing User Stories - INVEST

Writing User Stories - INVEST

Writing User Stories - Responsibilities

Customer Team : Responsible for writing stories, keeping in mind INVEST

Developer : Help customer write stories which lack details, do not assume and always have conversation but have it at the point when supporting information is available

Writing User Stories - Trawling for Requirements

Role Modeling, Personas , Extreme characters

User stories workshop, interviews ( open ended and context free questions ) , observation & questionnaire

Writing User Stories - Trawling for Requirements

Delivery Input

Return Details

Refund Details(Based on Payment)

Returns/Exchange

Status

Low Fidelity PrototypeHigher Fidelity Prototype

Story Smell Catalogues

Stories are too small Interdependent StoriesGoldplatingToo many details Including user interface details too

soonThinking too far aheadSplitting too many storiesCustomer has trouble prioritizingCustomer won’t write and prioritize

stories

Questions

What does INVEST stands for?Who constitute the Customer team?What are the tools available for

trawling for requirements?

Managing

Managing - Planning

 75% of all US IT projects are considered to be failures by those responsible for initiating them. Half of the projects exceeded budget by 200% 31% of projects were cancelled outright  53% of the all projects was so worrying that they were challenged.

Too many variables, too far ahead and replanning with better information not planned for

Managing – Planning.Estimating

Establish definition of story pointsVelocity = (Story Points

Completed)/SprintPrevious velocity can be used to

estimateTools :

Estimating : Tasks, Triangulating with Card Wall, Planning Poker

Managing – Planning.Estimating

Managing – Cost.Resource

Developers are not Codys

Managing – Planning.Release

Two areas Features/Stories▪ Prioritization : MoSCow

Time ▪ Iteration Length▪ Time to complete - Product Roadmap▪ Move from story points to expected duration

Product will be ready for release in approximately 5-7 iteration

Managing – Planning.Sprint

Discuss a storiesFor each stories disaggregate into

tasks Small enough to be accurate

Developer accepts responsibility for each task Individually ensures estimate

What! No task for upfront design?

Managing - Controls

Release Burndown charts – sprint (x-axis)

Sprint Daily burndown charts – day (x-axis)

Daily NotStarted,InProgress,Completed -

Cardwalls Standup

Managing - Rules of the Game

No changes to during a sprintCustomer stay involves all the time

User Stories

Not IEEE 830 Use cases – sized to deliver business value, “level of detail”

Why Emphasize of quick chat Comprehensible by everyone Right size for planning Works for iterative development Defer details to a right point in time Support opportunistic design Encourages participatory design Build up tacit knowledge

Stories may not be good ISO 9001 companies – Will have an issue with tear up stories

Team Practices

Start off with simple design, but expect changes

Refactoring ( and consequently test ) is important

Test Automation is crucial

Architecture, UML, use cases and agile software development

Middle out

Questions

What are the tools used in estimation?

What is done in Release Planning?What are the tools used in Release

Planning?Completion vs Number of Stories

Points – which is preferred?Name the Team Practices.How do you deal with unplanned

tasks?

The Journey

The Journey - Build

The Journey - Communication

Summary

You can’t do agile you just have to be agile

Q&A

Reference

User Stories Applied for Agile Software Development – Mike Cohn – Addison Wesley

http://www.thoughtworks.com/what-we-say/presentations/AgileMadeUsBetter.pdf

Behavior Driven Development - Scott Belware - http://www.code-magazine.com/articleprint.aspx?quickid=0805061&printmode=true