Anatomy of a User Story

As a {user role}I want to {goal} so I can{reason}

As an {ATM user} I want to {deposit money into my bank account} so I can {increase my account balance}

• Acceptance tests provide basic criteria that can be used to determine if a user story is fully implemented
  


• Having criteria that tells us when something is done is the best way to avoid putting too much, or too little, time and effort into it
  

• Acceptance tests provide a great deal of information that the developers can use in advance of coding their story

• Describes desired functionality from the customer‟s, purchaser‟s or user‟s perspective

• A simple, written description of a piece of functionality that will be valuable for the user or owner of the software

• A “good” user story describes the desired functionality, who wants it, how and why the functionality will be used, and is not technical

As a <role> I can <activity> so that <business value>
where:
• Role – represents who is performing the action or perhaps one who is receiving the value
from the activity.

• Activity – represents the action to be performed by the system.

• Business Value – represents the value to the business.

… a unit of work to develop functionality that:

• Is very specific (has concrete examples)
• Provides value to the customer
• Can be tested independently of other (later)
features
• Can be finished in a single iteration
… consists of 3 major components

Story Card + Conversation + Story Tests

A measure
of a team’s rate of progress. It is calculated by summing the number of story
points assigned to each user story that the team completed during the iteration.

Velocity = completed 3 stories x 5 point/story = 15

Velocity = completed 2 stories x 5 point/story = 10

Story Point

A user story estimated as ten story points is twice as big, complex, or risky as a story estimated as five story points. A ten-point story is similarly half as big, complex, or risky as a twenty-point story. What matters are the relative values assigned to different stories

A number in the Fibonacci sequence is generated by taking the sum of the previous
two numbers.

1, 2, 3, 5, and 8......

a very useful estimation sequence because the gaps
in the sequence become appropriately larger as the numbers increase. A onepoint
gap from 1 to 2 and from 2 to 3 seems appropriate just as the gaps from 3
to 5 and from 5 to 8 do

The three most common techniques for estimating are:

• Expert opinion
• Analogy
• Disaggregation

The Product Owner can verify that the story was implemented as intended

Developers and testers know when they are done

Test Data

designing test approaches

evaluating risks

Take the smallest piece of testable code

isolate them from the rest of the system

determine if the results are as expected

• What did we do well, that if we don’t discuss we might forget?
• What did we learn?
• What should we do differently next time?
• What still puzzles us?

1 Retrospective Plan

with a Clear Target

Set the stage

gather data

generate insight

decide what to do

close the session

Identify a goal for the session:

Improve Practices

Identify Bottlenecks

Why we have this-and-that issue

2. Make the session unique

Planning
unique variations of retrospective sessions gives the participants
a chance to look at issues from many perspectives.

Ask questions, use activities
which make it easy to participate and bring out opinions, emotions
and concerns.

What have been the high points of this sprint?”

5. Aim for a suitable amount of SMART goals

Specific, Measurable, Attainable, Relevant
and Timely.

Retrospective Process

Pluses and Deltas

Retrospective Processes

Wind and anchors

Retrospective Processes

ORID