Story - StickyMinds

Transcription

Story - StickyMinds

AW11
Class 6/9/2010 4:00:00 PM "Story-o-types: The Patterns Within the
Stories"
Presented by:
Dan Rawsthorne
Danube Technologies
Brought to you by: 330 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com
Dan Rawsthorne
Danube Technologies, Inc.
A software developer for more than twenty-five years, Dan Rawsthorne is an
accomplished manager, mentor, coach, trainer, consultant, and architect. His experience
runs the gamut—from e-commerce to databases to military avionics and air traffic
control. Dan is an agent of change, helping organizations transform themselves through
liberal applications of common sense and agile techniques. His formal training causes
him to look for underlying problems rather than to focus on surface symptoms; his
military background helps him understand the importance of teamwork and
empowerment; and his common sense tells him that change must happen in small
manageable bites. Dan is currently co-writing Exploring Scrum.
Dan Rawsthorne
Certified Scrum Trainer
Senior Coach
CollabNet
drawsthorne@collab.net
Storyotypes
The Patterns Within the Stories
Agile Development Practices
June 9, 2010, 4:00 - 5:30
1
©2010
Dan Rawsthorne: StoryoTypes
Abstract
Intro
Brief Description of Scrum Team
Background on Stories
How I Found Storyotypes
Uses of Storyotypes
Agile Analysis Overview
Story’s “Doneness” Agreement
Organization “Need” to Standardize
Examples
Categories of StoryoTypes
“Basic” Development Storyotypes
Other Development Storyotypes
We Could Even Have Storyotypes for Epics
Analysis Storyotypes
Other Storyotypes
Summary
2
©2010
3
©2010
The Basic Scrum Engine (Scrum Team)
Stakeholders
Business
Owner
SME
SME
Scrum
Master
SME
SME
4
Product
Owner
©2010
Walls of the Box:
Time-boxing
Impediment
Resolution
Cross-functionality
Self-Organization
Self-Management
Self-Contained
Definitions of “done”
Getting Work Done (the RASCI model)
R esponsible – the Team Members are Responsible for the work the
Team agreed to
A ccountable – the Product Owner is the only Team Member
Accountable to the Business for the work the Team has committed
to
S upportive – The ScrumMaster is Supportive of the Team by
facilitating its self-organization, coaching in scrum, removing
impediments, and so on…
C onsulted – external Subject Matter Experts (SMEs) are Consulted
by Team Members if necessary. No one outside the team is either
Responsible or Accountable for work the Team has committed to
I nformed – all external Stakeholders are kept Informed of what the
Team has committed to, and the progress the team is making
5
©2010
6
©2010
What is a Story?
A “promise for future conversations” – Cockburn
A small unit of work that provides value
Both a requirement and an activity
Introduced by eXtreme Programming (XP) as a
user story – something that a user needs
Adopted by most scrum advocates – like myself
– with appropriate changes
7
©2010
Evolution of the Story concept
XP (Beck, Jeffries, et all) introduced the “user story” as a
way to drive small agile teams as “one thing the customer
wants the system to do”
All about production
Brilliant combination of requirement and activity
Scrum (Schwaber) says that the scrum team has all the
skills you need to get the job done:
Analysis, design, coding, test, QA, documentation, training, etc
Whatever you define “done” to be for your team
So…
8
©2010
User Stories aren’t the only Stories in Scrum
In Scrum, the Team does ALL the necessary work
And it’s all managed by stories
Not just User Stories
So, we must have many different kinds of potential
stories:
Analysis stories
Development stories (user stories)
Infrastructure / environmental stories
Business Support stories
Etc
And, we expand the definition of story to be
A small unit of work that provides “project value”
Promise for future conversations
9
©2010
Sample Work Breakdown Structure
CatAir.com Proj
Product
Capability
Team
Management
Sales Spt
Team
Training
Marketing
Support
Conversions
Dev/SCM/Test
Environments
User
Training
Rewrites
Dev
Process
User Docs
Refactorings
App
Framework
Business
Framework
Tools
Adapt
Processes
Maintenance
Docs
…
Quality
Sell e-Ticket
Status of
Flights
Cross-Sell
Hotels
Cross-Sell
Cars
Pilot
Timesheets
Good Cust
Plan
…
10
©2010
Business
Prod Env
…
…
11
©2010
Making Better Stories
I was coaching a team that was using Stories for their
scrum project
We were wondering what good stories should look like
We knew INVEST(Bill Wake, 2003)
Independent – don’t overlap in concept, implement in any order.
Negotiable – they are “promises for conversations”
Valuable – provide value to the customer
Estimable – might require a spike to be able to estimate
Small – a few person-days of work
Testable – figure out how to know you’re “done”
But this wasn’t enough… we were still confused…
Had particular problems with Independent and Testable for noncoding stories…
12
©2010
We Tried Developing a Story Template
Title (required) – unique, descriptive, moniker for the story
Description (required) – often in Connextra form:
‘as a <role> I want <something> so that <I get this value>’
Story Boss (optional) – the team member responsible for managing the story to
completion
Origin (optional) – the source of the story; includes its parent epic
Dependencies (optional) – other stories that depend on this one, or that this one
depends on
SMEs (optional) – the people who “know about” this story
Size (required) – an estimate of complexity for the story, usually represented Story
Points, t-shirt sizes, etc
Business Value (optional) – a statement of how much this story is “worth”
“Done” Criteria (required) – our actual contract, our validation criteria
Notes (optional) – whatever you want to help in the conversations the story
represents
Tasks (required) – eventually, you actually need to do some work…
But this didn’t really work… too complicated
13
©2010
Discovery of Storyotypes
The problem was starting to get to me… so
I googled on “type of story” and found a great paper
Gerard Meszaros: “Using Storyotypes to Split Bloated XP Stories,”
XP/Agile Universe 2004
This paper showed me several things:
How to decompose a Use Case into User Stories
Helped expand what I knew from Cockburn’s “Writing Effective Use Cases”
book
That the right size of a story was one “positive test”
That each story should have only one focus
Don’t combine adding functionality with getting a “good” interface
These are all important lessons, BTW
14
©2010
Incorporating Definition of “Done”
About this time, the focus on “done” was just coming about
I had coined the term “done/done/done”
The concept of “done” was just coming clear…
It was clear that stories that were alike had “the same”
doneness criteria
Actually, turned into my primary definition of “alike”
I realized the Storyotypes were the tool we needed to capture
the “doneness” criteria for similar stories
So, that’s where we are today…
15
©2010
Discussion
Talk amongst ourselves…
Have any of you gone through a search to try to write better
stories?
Talk to each other about your journey…
5 minutes
16
©2010
To Summarize: What Storyotypes Do For Us
Help us analyze and decompose epics
Especially Functional Ones
Help us capture “standard” doneness criteria
For Development stories
For Analysis stories
For Cleanup stories
etc
Goals
That a team grooming the backlog would “instantly” recognize 80%
of the stories they need to extract from epics
That the “Doneness” criteria for the stories will be easier to
recognize and commit to in planning
17
©2010
Backlog Evolution
Items
Tasks
To Do
In Progress
Done
Front Burner
Acceptance
StoryoTypes
Help Here
Back Burner
prioritization
Grooming
Complete the Work
Fridge
In Box
New
In or Out of Scope
Freezer
18
©2010
Done
Abstract
Intro
Uses of Storyotypes
“Doneness” Agreement
Examples
Other Storyotypes
Summary
19
©2010
20
©2010
Analysis: Product Capability Story
Analysis is primarily about Decomposition
Our Product decomposes into Capabilities
Capabilities are implemented by doing stories
But not all stories are capability-driven
Our Project’s work can be seen as a collection of Stories
But we’re only going to focus on the capability-driven ones
Incremental Analysis is (basically):
Find the Capabilities, validate them, then
Find the Stories, and validate them
Then we use the stories to drive development…
Product
21
Capability
©2010
Story
Agile Analysis
I thought about Agile Analysis a little bit too hard…
Before I discovered Storyotypes I went a little nuts…
What Should The
Product Do?
Visions
Capabilities
For each Defect/Refinement/AddOn
For each Capability
What Do We Want
To Happen?
Stakeholder
Desirements
How Do We Make
that Happen?
Stories
Interaction/Path/Algorithm
Storyboard/Wireframes
Testing Strategy
…etc…
What Pieces Do
We Need?
What Else Do We
Need?
22
©2010
Other Capabilities
Other Systems
UI/Data Elements
Interfaces
Sensors
Business Rules
Functional Tests
…etc…
Design and
Development
Capability Defect/Refinement/AddOn
Agile Analysis
Is actually pretty straightforward
Agile Analysis is simply the finding of development stories,
nomatter how we do it
Can be done through standard Requirements Analysis
Can be done through Testing
PO (or Analyst) responsibility in all this…
Communicate with Product Owner and Business Stakeholders
Describe what’s being built
10-50,000 foot view
Produce and Explain Stories for Development Team
Ground-level to 5,000 foot view
Work with Coders, Designers, Testers, Etc
“Promise for a Conversation” - Alistair Cockburn
23
©2010
Stories Resulting from Analysis
Are put on the Backlog
May not be the right size for developers, yet…
This is a different problem than the one we’re looking at now
We want to make sure we have the “right” stories,
Not that the stories are “right”
It’s ok that they’re epics now – the team will tell us when to dig in and
split
Then, we’ll use these stories as a “promise for a
conversation”, and start digging into them and making them
work for us…
“They (the POs) told the developers what the customer wanted in the
way the developers wanted to hear it” – Jeff Sutherland
24
©2010
(Use Casey) Analysis Concept on One Slide
“Connective Tissue” stories
Backbone
Capability
System
25
Minimum,
end-to-end,
Demonstrable,
Architecturally-Significant
functionality
©2010
Releasable
functionality
“S-Shaped Curve” for Delivering Business Value
"S-Shaped" Curve
1
critical mass point
Earned Business Value
0.9
0.8
Buffer
Rework
Nice to haves
0.7
0.6
0.5
architecturally
significant
0.4
Must haves
0.3
0.2
0.1
0
0
20
40
60
80
100
% of BV-Producing SPs
Our PO’s job is to have the Team do the stories in the “right”
order to keep the value produced on the S-Shaped curve
26
©2010
“80/50 Curve” for Delivering Business Value
And we just use the 80/50 curve if there is no Architectural
component…
"80/50" Curve
critical mass point
1
0.9
Earned Business Value
0.8
Buffer
Rework
Nice to haves
0.7
0.6
0.5
0.4
Must haves
0.3
0.2
0.1
0
0
20
40
60
80
100
% of BV-Producing SPs
27
©2010
How Much Detail?
The key thing is that the stories we find are “fit for use” – that is,
they are what the developers need
It is not about “getting what they know” from the stakeholders; it
is about being able to have the right conversations with them
later…
Could include some “designey” stuff
Business Rules
GUI stuff
Storyboards, Wireframes, Mockups
Etc
But not too much
It’s about getting enough so that the Team can commit to the Story
The details will be found in future conversations
Not about “getting it right” in the initial story
28
©2010
Discussion
Talk amongst yourselves
How easy is it to find “good” stories
How do you do it?
5 minutes
29
©2010
Story’s “Doneness” Agreement
30
©2010
Driving Development With Stories
As a <Martian> I want
<interesting cover art that
reminds me of earth> so
that <I’ll be attracted to
your travel agency>
31
Tasks
Not Started
In Progress
Sprint Backlog
Agreement:
1. Make two versions
2. Sue chooses one
3. Make sure is on PostIt
so that we can move it
around
Stories
©2010
One of the Main Things…
Is the Story’s Agreement
This tells the Team how they will know that they are done
This is the “actual” requirement for the Story
Must be something the team controls
Nobody from the outside can tell you if you are done or not
Verification is an intrinsic part of development
You own it
Remember the Product Owner is part of the Team
PO and rest of team negotiate the Agreement for the Story
32
©2010
Completed
Parts of the Agreement – External and Internal
Acceptance Criteria
What we “Deliver”
Externally Visible
Definition of Done
Technical Debt
Invisible from Outside
33
©2010
Common “Agreement” for Coding Stories
•
A List such as the following is often “on the side” of the StoryBoard, for
use by the Team when considering any and all coding stories
•
•
•
For all Coding Stories, make sure that…
34
It works as a reminder of what to think about, and leads to storyotypes
For each individual story, the team must “pick and choose” which items apply to this
story.
UI design reviewed in ‘paper’ form
Logical Data Model reviewed
Functional Test strategy (test cases) reviewed
Periodic reviews with SME/Analyst
Functional Tests running on Integration box
Have automated unit tests protecting all class interfaces
Regression tests (consisting of everybody’s unit tests) “green bar” on Integration box
Information needed for documentation, training materials, and the like are captured
Frequent pairing or peer reviews so that we have a second pair of eyes on ‘everything’
Do the XP practices as much as you are able
Peer reviews to assure code and design standards are met
©2010
Iron Triangle and “Doneness”
Effort
balance
Agreement List
---Tests to Pass
Time Boxes
-Inspections
Process Reqts
Agile Planning is actually about balancing effort, scope, and technical
debt
The expected scope and debt is seldom documented in detail, but
maybe if should be
I like to see an explicit list so that we can “check it off”
Agreement has two parts concerning “doneness”
Scope Side (acceptance), usually defined by tests, time boxes, etc
Debt Side (doneness), usually defined by inspections, process steps, etc
The Lists are different for different storyotypes, and the tasks must
conspire to get the list completed
35
©2010
Form of the Agreement
These agreements have different forms for different
kinds of stories (storyotypes), but for a functional
story there are three parts to an Agreement:
General Agreements: like which SMEs will we talk to? What
are the simplifying assumptions? etc
Acceptance Criteria: What will be verified to prove that the
story provides the stakeholder-requested value?
Definition of Done: What will be verified to prove that we
have mitigated the risk of producing technical debt?
These functional stories are the easiest to
understand
We’ll show some examples of various types
36
©2010
Seeing is Believing…
Probably the best way to understand this concept is to
see some examples
In the following examples, we some “complete” stories –
stories that have been committed to
What we see here defines the “what” for the story
The “how” will be explored, defined, and implemented as the story
is worked on
There could be more stuff than this, but we usually defer it until we
have committed to actually doing the story
First we’ll look at some stories of different types, and then
we’ll discuss Epics
37
©2010
Sample Development Story
Tasks
Get List of Flights from CUTLASS
Size: 8 SPs
Type: [backbone]
As a <flyer> I want <to have a list of
flights that matches my itinerary> so that
<I can choose one that works for me>
Architecture
and Design
32 hrs
General:
- Joe (SME) is the expert on CUTLASS
- Simplifying Assumptions: One Way, Single Leg, No
Seat Selection, Single Passenger, Full Fare, No
Luggage …
Write Functional
Tests
Acceptance:
Pass in an itinerary and get a list of Flights back
Doneness:
Review Architectural Decisions with Team
Design Review
Review Functional Test Strategy
Review Unit Tests
Verify Tests passing on Development Machine
Code Review
Functional Tests Written
Verify Tests passing on Integration Box
Add Tests to Regression Test Suite
38
©2010
12 hrs
Code and Unit
Test
80 hrs
Sample Analysis Story
Tasks
Analyze Shopping for Flights
Size: 2-day Timebox
Type: [analysis]
As a <developer> I want <some stories for
‘”shopping for flights”> so that <I’ll have
some work to do>
General:
- Amir (Team Member) is the Coordinator
Acceptance:
The backbone epic is in the Backlog
There is at least one validated backbone story,
based on this backbone epic, in the Back Burner
ready to be “worked on”
Doneness:
Identify SMEs and document in use case
Meet with the SMEs and:
Discuss the use case and document in the Wiki
Generate, and validate, the backbone epic
Decompose the backbone into at most 10 stories
Work with SMEs and Team to prioritize and move
at least 3 of these stories into the Back Burner
for further grooming
39
©2010
Meeting with
SMEs
4 hrs
Document in
Wiki
6 hrs
Generate
Production
Story
4 hrs
Sample Infrastructure Story
Install Copy of CUTLASS in Lab
Size: 8 SPs
Tasks
Type: [enviro]
As a <developer> I want <to have my own
copy of CUTLASS to play with> so that <I
can figure out how it works>
General:
- Joe (SME) is expert on CUTLASS
- Sam will be CUTLASS expert on Team
Set up clean
machine in lab
8 hrs
Acceptance:
CUTLASS is “up and running” in the lab
Doneness:
Get CUTLASS Install from SirJeff
Set up clean machine
Install CUTLASS
Do Smoke Test to see if it works
40
©2010
Install
CUTLASS on
new machine
8 hrs
Discussion
What about this?
Do you have this much information when you start?
More?
Less?
If not, why not?
And, how’s that working out for you?
5 minutes
41
©2010
42
©2010
Scrum Teams Live Within an Organization
That can provide constraints upon the Scrum Team
The Team’s process is part of an overall process
The team owns what is not constrained
What should an organizations constrain?
What process issues are cross-cutting ones?
Product
Management
Team
Project
Management
Team
Dev
Team
43
Project
Development
Team
Dev
Team
©2010
Project
Management
Team
Dev
Team
Dev
Team
Dev
Team
Organizational Issues
Organizational Issues:
Common Codebase across Teams
Want to move people from Team to Team
Want commonality of “process”
Scrum wants:
Self-organization, self-management, and freedom for teams
A good candidate for standardization across teams is
“Storyotypes”
Cross-team integration issues
Makes it easier for people to move from team to team
But doesn’t micromanage the people themselves…
44
©2010
Cross-Team Integration
Integration is always hard – probably the biggest technical
issue in most organizations
Common “Def’n of Done” helps integration issues
Know “what to expect” from the code you are integrating with
Know “what to expect” if you need to work with somebody else’s code
Know “what to expect” if you need to work with people from other teams
Allows for cross-team Retrospections about what “done” should
mean
Good for the codebase
Good for the organization
45
©2010
Makes it Easier for People to Move
A Common Definition of “Done” Leads to common
development practices
So, at the “working together” level it makes it easier for people to move
from team to team
Makes it easier to do technical training for an organization
But, it gives the team flexibility
To adapt their own team dynamics to their team members
To add more restrictions to the def’n of done for their team
And it’s not micro-managing
It’s more of a “what” thing – it’s telling people what they need to do…
It’s putting constraints on the hows, but not defining the hows
46
©2010
Discussion
Does your Organization feel the need to “standardize”
How’s that working out for you?
5 minutes
47
©2010
Abstract
Intro
Uses of Storyotypes
Examples
Other Storyotypes
Summary
48
©2010
Categories of Storyotypes
49
©2010
Categories of Storyotypes
Storyotypes
Stereotype of a story
Meszaros, “Using Storyotypes to Split Bloated XP Stories”
2004, XP/Agile Universe
I extend the concept beyond “coding” stories to all
types of stories we find in scrum projects
There are various Categories of Storyotypes that I
use
50
Production (coding)
Analysis (finding stories)
Business Support (non-coding)
Chores (no immediate Business Value, but not Analysis)
©2010
49
51
©2010
Coding Storyotypes Catalog (use cases)
[usecase] – the epic that represents the use case itself
[coding] – generic for writing code (many companies
do this)
Use Case Based Storyotypes (from Meszaros)
[backbone]
[alt]
[beefup]
[interface]
This is where it all starts
And gives us much of the value of storyotypes
And we’ll add some more after that…
52
©2010
Use Case Based Storyotypes
Use Case
Implemented by
Story
Made up of
Conform to
Backbone
Scenario
Storyotype
Many of them
Single thread
Always another one…
Alternate
[usecase]
The use case itself
[backbone]
[alt]
A Story on the backbone
An alternative scenario
[beefup]
[interface]
53
Only one
Architecturally significant
Simplifying assumptions
Single thread
Improving a business rule in an existing scenario
Improving the interface for the UC
©2010
53
Example: Stories for “Buy an e-ticket” Capability
[usecase] Buy an e-Ticket
[backbone] Get List of Flights from CUTLASS (ugly interface)
[backbone] Capture Itinerary Information
[backbone] Capture Passenger Information
[backbone] Reserve Flight in CUTLASS
[alt] Modify CUTLASS to Understand When Flight is Full (note: was awful!)
[analysis] Analysis Meeting with SirJeff
[backbone] Pick One Flight and Pay for It (note: stubbed out actual payment)
[alt] Handle Round Trip Flights (ugly Interface)
[beefup] Hook Up Actual Visa/MasterCard Processing Widget (note: was a PITA)
[backbone] Issue email Confirmation to Customer
[interface] Improve Interface for buying e-ticket
[beefup] Close Reservations when Plane is Full (note: turned out to be easy)
[alt] Add Payment with PayPal (note: really straightforward)
[alt] Reserve Flight to Pay upon arrival at Airport
[alt] Handle multiple-Passenger Parties
[interface] Web Interface for Adding/Modifying Flight Info
[beefup] Get Luggage Info, including Scuba Tanks
[analysis] Exploratory Testing to "See What's Left" for Buy an e-Ticket
[spt] Make sure SirJeff’s Marketing materials have correct information
[bug] Fix Bug in Luggage Weight Calculations
[bug] Fix Small List of Bugs found in Exploratory Testing
[alt] Pay with AMEX
[alt] Bring Pet on Board
[beefup] Special Needs (wheelchair, etc)
[alt] Select Seat online
[alt] Pay with Coupon
[beefup] Seat Belt Extender Needed for 'large' Passenger
[beefup] Special Meals
[alt] Change Seat online
[alt] Comfort Seat for 'really large' Passenger
[alt] Pay with PayPal
54
©2010
Fd
0
0
0
0
2
1
0
0
3
0
3
0
3
0
0
3
3
4
2
5
5
3
5
5
3
3
3
5
3
5
3
Dn
1
2
2
2
3
3
3
3
4
4
4
4
4
4
5
5
5
5
5
5
6
Size
L
L
L
L
L
S
L
L
L
M
M
L
M
M
L
L
L
S
S
S
M
M
M
S
M
M
S
S
M
S
M
Continuous
Analysis
As you move
along, you will
need to find new
stories “within” the
features
What we see here
is the list of stories
for “Buy an eTicket” that were
found /
implemented in
this release
The Cool Thing About these Storyotypes
They help us identify the Stories, once we have the Use
Case (part of Grooming)
Analyzing, looking for specific storyotypes
“do we have an alternative scenario?”
“do we need to beef up an existing scenario?”
“do we need to clean up the interface?”
We get the basics of the Agreement for “free”
This makes effort estimation and commitment much easier
Basically, storyotypes make much of producing the
Backlog easier
Extracting stories from Epics (grooming)
Standardize Story Agreements (commitment)
55
©2010
Backlog Evolution
Items
Tasks
To Do
In Progress
Done
Front Burner
Acceptance
StoryoTypes
Help Here
Back Burner
prioritization
Grooming
Complete the Work
Fridge
In Box
New
In or Out of Scope
Freezer
56
©2010
Done
Basic [coding] Story Agreement
[coding] Story
General
The SMEs for this Story are XXX, YYY, and ZZZ
Acceptance Criteria
“Black Box” Test[s] and need to pass
Doneness Definition
Functional Test Strategy Review
Information needed for documentation, training
materials, and the like are captured
Design, Code, and Unit Test Peer Reviews
Verify working on Development Machine
Have automated unit tests protecting all class
interfaces
Functional Tests Written
Verify working on Integration Box, including all Tests
Add All Tests to Regression Test Suite
57
©2010
Do XP
Other Use Case Storyotypes
[coding] story
[backbone] story
Review Architectural Decisions
with Team and Architecture SMEs
Review Simplifying Assumptions of
backbone and review “handoffs”
between [backbone] stories
[beefup] story
Verify Business Rule with SME
[alt] story
Review business importance of
scenario with SMEs and Team
[interface] story
Review Interface design with UI
SME and Team
Informal Usability Testing and make
improvements
Not surprisingly, the different Storyotypes add a
few more things to the mix…
58
©2010
57
Discussion
Would something like this be useful to your developers?
5 minutes
59
©2010
60
©2010
Other Coding Storyotypes (examples)
Other Coding Storyotypes
[perf] – actually an epic, requires strategy for decomposition
[bug] – work directly with originator of bug
[cleanup] – for cleaning up bad code
Need to capture what needs cleaning up, refactoring, unit tests, design,
whatever…
[documentation] – for finalizing documentation from info already
gathered as part of [coding] stories
Mixins
[hack] – intentional hacking, always comes with a [cleanup] story
[arch] – architecturally significant
Makes an important decision
Need review by team, or architecture team, or something
[UI] - UI design reviewed by “UI SME” added
(DB] - DB design reviewed by “DB Guy” added
61
©2010
Other Production Storyotypes
There are many other Production Storyotypes we
could have. Some examples are…
[spike] – a research story, usually involving coding. It can
easily turn into an epic or a project…
[documentation] – assemble the documentation details into a
document for use, either for users, maintainers, whatever
[training materials] – similar to documentation
[integration] – in large teams (multiple small teams) we need
a story to explicitly integrate pieces produced by the different
teams
What the Agreements are for these are “left to the
user”
62
©2010
We could even have Storyotypes for Epics
63
©2010
Discussion of Epics
Epics are Items that the Team can’t commit to, for any
reason (Complex, Unknown, Risky, or Big)
Has other Stories inside it
There is usually no definition of “done” for an epic, but
These inside stories have Agreements that can be committed to
Example:
Epic: “I want page XYZ to render in < 1/10 sec because it’s too
slow right now”
Epic because team can’t commit to 1/10 second (too risky)
Stories inside could be:
Do 4 hours worth of improvements to the rendering and measure to see
how fast it is
Implement algorithm ABC to speed up the rendering
Etc
Note that what the stakeholder will get is NOT what
they want – it’s what the team can commit to…
64
©2010
There are Various types of Epics
Here’s a sample
[epic] – so big it needs to be decomposed
Different kinds of [epic]s decompose differently
[usecase] (seen this one already)
SMEs for the Use Case are …
Constraints for Backbone are…
[maintenance] – for holding bug list for a particular product
[maintenance] SouvSite Bugs
Would usually hold [bug] stories
[perf] – an epic for “scooching” up on a performance goal
[perf] Increase Rendering Speed on XYZ Page
[perf] Handle 100,000 simultaneous users
[issue], [dependency] – tags to remind us something must be managed,
and the stories that manage it live in here…
What else?
BTW, this may be thinking too hard…
65
©2010
Storyotypes
by Dan
Dan Rawsthorne:
StoryoTypes
66
©2010
Rawsthorne
65
Analysis Storyotypes Catalog
Remember, analysis stories are stories the Team does in
order to find new stories
There are many kinds of analysis, including
Studying source material
Working with Stakeholders
Processing Change Requests
Exploratory Testing
Usability Testing
Etc
Each of these methods is used at different times, and for
different reasons, in the project
But the goal is always to find new, valid, prioritized stories
And put them on the Backlog
67
©2010
Analysis Storyotypes (examples)
[analysis] story
General
define focus of analysis
SMEs for this are xxx, yyy, zzz
Acceptance Criteria
document new stories in backlog
work with PO to prioritize stories
verbal report to Team
Definition of “Done”
timebox the work
[paper analysis] story
get docs and other sources
validate new stories with SMEs
[exploratory testing] story
Verify focus of testing
68
©2010
[process requests] story
validate new stories with requestors
[work with stakeholders] story
schedule a facilitated meeting
prepare for innovation game
summarize the results
Discussion
What kinds of analysis do you do in your projects?
How do you control it in your backlog?
5 minutes
69
©2010
Storyotypes
by Dan
Dan Rawsthorne:
StoryoTypes
Other Storyotypes
70
©2010
Rawsthorne
69
Short and Sweet
These Storyotypes are relatively straightforward, so I’ll just list
them by category
They exist because:
They provide value to the business, project, or product, if not to the user
We have to do these things, so must plan for them – so there are stories
There are common patterns across projects and organizations – so there
are storyotypes
71
©2010
Infrastructure/Environment
“Set Up” Storyotype – Makes our team able to do
work better and easier
Set up CM Environment, Development Environment, Test
Lab, Etc
Team Training – courses, internal training, etc
Add a Tool – “Install FITnesse”
Improve XXX – “New build process”
72
©2010
Business Support Storyotypes
Used to provide support to the Business. They
provide Business Value, but aren’t developing
product
73
[sales meeting]
[trade show]
[train users]
[support help desk]
etc
©2010
Chore Storyotypes
Used to set up or improve the Team’s
environments, infrastructure, etc
[new tool]
[new hardware]
These storyotypes are much more “ad hoc” than
the previous ones
74
©2010
Abstract
Intro
Uses of Storyotypes
Examples
Other Storyotypes
Summary
75
©2010
Summary
Doneness criteria contribute to a Team’s success
Different kinds of stories have different kinds of doneness
criteria
Doneness criteria are good candidates for standardization
in an organization
Same codebase
Same development environment
Somewhat the same process
Storyotypes are a method for capturing these
standardized Doneness criteria
For training
For retrospections
For helping people move from team to team
76
©2010
Any Questions?
77
©2010
Thank You Very Much!
78
©2010

Story - StickyMinds

Transcription

Similar documents

Yamashita Yamashita International International International

Boss Hawg`s Bar

seeing the light - DeMontfort Fine Art

File

SAVE THE DATE: Monday, April 28, 2014

to PDF

Dan Reeder - Miss Brooks` Classroom

- Walnut Hill Bible Church

Chef`s Shoppe

Photos shown November 5, 2012 at University of