Who I am?
Name: Dipl.-Ing. Sebastian Sussmann easier, just call me: Sebi
Skype: sebastian.sussmann.home
Email:
[email protected]
8/8/2012
www.axonactive.vn
1
SCRUM
8/8/2012
www.axonactive.vn
2
Agile knowledge
8/8/2012
www.axonactive.vn
3
Why are we here? Software development
8/8/2012
www.axonactive.vn
4
Key points
Idea
parameter
Scope (output)
Budget
Time
Involved person
Manager
Customer
Worker
Steps
Flow
Framework
Process
Planning
Monitoring
Quality
Satisfaction
Quality
Get what he want and more
8/8/2012
www.axonactive.vn
5
How does it work?
Create first
version
Take out of
service
Changes until
the customer
is happy
improvement
Deployment
8/8/2012
www.axonactive.vn
6
How can it work?
Just for really small things
Create first
version
Take out of
but not for projects
service
Changes until
the customer
is happy
Whenimprovement
the process is too
complicated for the
defined
approach, the
Deployment
empirical approach is the
appropriate choice.
-> AGILE Methods
8/8/2012
www.axonactive.vn
7
Software process
W a te r fa l l mode l
S p i ra l mo d e l
R a ti ona l U ni fi e d P r oc e s s (R U P )
Op e n U n i f i e d P ro c e s s
P ro t o t yp e Mo d e l
V -M ode l
W -Mo d e l (w i t h p re t e s t p h a s e )
E x tr e me P r ogr a m mi ng (X P )
C rys t a l Fa mi l y
XU P : XP + R U P + MS F
OP E N
S c r um
K a nba n I T
S t a g e -Ga t e -Mo d e l
P e rs o n a l S o f t w a re P ro c e s s
P l a s t i c I n t e rf a c e f o r C o l l a b o ra t i ve Te c h n o l o g y I n i t i a t i ve s t h ro u g h V i d e o E x p l o ra t i o n
P ro c e s s P a t t e rn s
E n t e rp ri s e U n i f i e d P ro c e s s
A g i l e U n i f i e d P ro c e s s (A U P )
Mi c ro s o f t S o l u t i o n s Fra me w o rk
C a t a l ys i s
Te a m S o f t w a re P ro c e s s
P r ototypi ng
Mo d e l D ri ve n S o f t w a re D e ve l o p me n t
Fe a t u re D ri ve n D e ve l o p me n t (FD D )
Te s t D ri ve n D e ve l o p me n t
H e rme s (E D V ) s w i s s p ro je c t mo d e l
a c t i F: A g i l e p ro je c t mo d e l
R OP E S (R a p i d Ob je c t -o ri e n t e d P ro c e s s f o r E mb e d d e d S ys t e ms )
C MMI (C a p a b i l i t y Ma t u ri t y Mo d e l I n t e g ra t i o n )
I S O 1 2 2 0 7 , S o f t w a re L i f e C yc l e P ro c e s s e s
I S O 1 3 4 0 7 , U s e r Ori e n t e t S h a p i n g I n t e ra c t i ve S ys t e m
I TI L V 3 (s e t o f b e s t -p ra c t i c e s f o r I T s e rvi c e ma n a g e me n t (I TS M))
...
Source: http://de.wikipedia.org/wiki/Liste_von_Softwareentwicklungsprozessen
8/8/2012
www.axonactive.vn
8
waterfall
Requirements
Design
Code
Test
Maintenance
8/8/2012
www.axonactive.vn
9
waterfall
-Simple framework
-Looks like simple
management effort
-looks like a visible
process
Requirements
Design
Code
Test
-Sequential steps not every time
useful or not possible to do
-No feedback
-No risk analysis
-Discover problems only at the end
-User requirement only at the
beginning
-Risk of miss understanding
-Risk to get to much documentation
-sequential oriented
-...
Maintenance
8/8/2012
www.axonactive.vn
10
Prototype model
Prototype specification
Produce the prototype
Play around
Experimentation
yes
Accepted?
no
Changes and extend
8/8/2012
www.axonactive.vn
11
Prototype model
Prototype specification
Produce the prototype
-Maybe useful
integration in other
project models
-Get a fast user
feedback
-Producing fast
“software”
Play around
Experimentation
Accepted?
no
-If thisyes
is a main model it will have
yes
a big development
effort
-No documentation
-No maintenance possible
-Risk that this prototype will be
used
-sequential oriented
Changes and extend
8/8/2012
www.axonactive.vn
12
XP (Extreme Programming)
Driven by coding
the most important question is:
how to solve the coding,
This mean produce software
With close customer relation
Light documentation,
Mostly the customer
is not able to describe what he need
It needs a big interaction between
Customer and developer
The lifecycle
Month: release plan
...
Minutes: code / test
Source: http://en.wikipedia.org/wiki/File:Xp-loop_with_time_frames.svg
8/8/2012
www.axonactive.vn
13
XP (Extreme Programming)
Driven by coding
the most important question is:
how to solve the coding,
-The risk will be
checked regularly
-Best practice
-Realize the problems
early
-close customer
contact
-Fast first result
This mean produce software
With close customer relation
Light documentation,
Mostly the customer
is not able to describe what he need
It needs a big interaction between
Customer and developer
-No Transparency
-No Reusability
-It need trust
-Risk
The lifecycle
Month: release plan
...
Minutes: code / test
Source: http://en.wikipedia.org/wiki/File:Xp-loop_with_time_frames.svg
8/8/2012
www.axonactive.vn
14
Kanban
•
•
•
•
Continuously prioritized queue
Continuously deployment
Development and maintenance, combined
Visibly and easy to use
8/8/2012
www.axonactive.vn
15
www.axonactive.vn
16
Scrum on a beer coaster
Source: http://www.it-agile.com
8/8/2012
compare
XP
Scrum
RUP
V-Model
Waterfall
Focus
Development
process
Development process
Project process
Business process
Business Process
Important
roles
- Customer
- Developer
- Product Owner
- Scrum Master
- Team
- Software
architect
-System designer
- Software
developer
Project manager
Risk
Analyses
Everybody
Product Owner
together with Team
Architect
Project manager
Project manager
Priority
Stories together
with customer
Product Owner
together with Team
Architect
-System designer
-Project manager
Project manager
Architecture
Developer
Team together with
Product Owner
Architect
Developer
Architect
Test
Developer
Team
Quality control
Quality control
Quality control
Changes
Developer
Product Owner
Architect
Configuration
manager
No changes
Documentat
ion
Everybody
Team
Architect
Everybody
For each step
Driven by
Code
Scope
Documents
Documents
Documents
model
Small and agile
Small and agile
Time boxed
Big formal
framework
A big formal
framework
fix
8/8/2012
www.axonactive.vn
17
compare
XP
Scrum
RUP
V-Model
Waterfall
Focus
Development
process
Development process
Project process
Business process
Business Process
Important
roles
- Customer
- Developer
- Product Owner
- Scrum Master
- Team
- Software
architect
-System designer
- Software
developer
Project manager
Risk
Analyses
Everybody
Product Owner
together with Team
Architect
Project manager
Project manager
Priority
Stories together
with customer
Product Owner
together with Team
Architect
-System designer
-Project manager
Project manager
Architecture
Developer
Team together with
Product Owner
Architect
Developer
Architect
Test
Developer
Team
Quality control
Quality control
Quality control
Changes
Architect
Configuration
No changes
ItProduct
isOwner
not easy
tomanager
compare
Everybody
Team
Architect
Everybody is For each step
because
the focus
Code
Scope
Documents
Documents
different
for allDocuments
Small and agile
Small and agile
Big formal
A big formal
fix
processes...
Time boxed
framework
framework
Documentat
ion
Driven by
model
8/8/2012
Developer
www.axonactive.vn
18
Planned metrologies
Sequential
Iterative
Agile
defined process sequential
defined process iterative
iterative agile
Waterfall
Spiral
Scrum
V Model
RUP
XP
Prototype
ITIL
Kanban
Lean
Heavy weight methodologies work in some instances,
but there are HIGH COSTS, and can be HIGH RISK in
using them in DYNAMIC ENVIRONMENTS
8/8/2012
www.axonactive.vn
19
Stacey matrix
Source: http://www.derailleurconsulting.com/blog/complexity-and-noise-in-systems-development-projects
8/8/2012
www.axonactive.vn
Source: Strategic Management
and Organizational Dynamics by
Ralph Stacey in Agile Software
Development with Scrum by Ken
Schwaber and Mike Beedle.
20
Sequential vs. overlapping development
Requirements
Design
Code
Test
Rather than doing all of one
thing at a time...
...Scrum teams do a little
of everything all the time
Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.
Source: Mountain Goat Software, LLC
www.axonactive.vn
21
Agile
Agile isn’t hype or a fad
It’s a process control framework for complex environments
It has always existed its not a new idea (see history)
and
Agile doesn’t work everywhere
Because Agile is not silver bullet !
Agile will not work and it will fail for example here:
- in really traditional engineering if the framework is fix
- Organizations which don’t ”accept” Agile thinking
- Very simple projects
(ok, it works, but these are simple enough to be done with any methodology)
8/8/2012
www.axonactive.vn
22
Goal and important features of Scrum
Scrum
Scrum is a Agile management framework
its used for incremental products
structure
Scrum will just mentioned about few rules
3 - ROLES (scrum team)
5 - EVENTS (meetings)
3 - ARTEFACTS (list of items)
Transparency
Inspection
Adaption
Definition of Done
8/8/2012
www.axonactive.vn
23
The goal and important features of Scrum
The process is Iterative / incremental
out put is always a potential shippable product increment.
That the customer will always get and see a result.
Time box / cycle
Everything is time boxed (all meetings)
Everything will be repeated and improved as a cycle
Documentation
the documentation is available but only the necessary documentation will be
done.
No overhead documentation
Its always better to show at least
something and the truth.
Promise a delay means nothing.
8/8/2012
www.axonactive.vn
24
Definition of Scrum
1913 Henry Ford
belt production
1948 – 1988 Taiichi Ohno
Toyota Production System (TPS) – Toyota Way - lean production (1990)
1986 Nonaka und Takeuchi
The New, New Product Development Game
to increase speed and flexibility
Its called „rugby“ approach and the whole process is perfomed by one cross functional team
1995 Ken Schwaber,
Schwaber, Jeff Sutherland
collaborated during the following years to merge the writings, their experiences, and industry best practices into what is now
now
known as SCRUM now
1999 M. Beedle, M. Devos, Y. Sharon, K. Schwaber, J. Sutherland
Scrum: A Pattern Language for Hyperproductive Software Development
2001 Ken Schwaber, Jeff Sutherland
defined the Agilen Manifest
Source images: scrum.org
8/8/2012
www.axonactive.vn
25
Who works with scrum
Microsoft, Sun, Sammy Studios, Siemens, CNA, State Farm, Nokia,
Sony Ericcson, Philips, BBC, IBM, SAIC, LMCO, Ariba, Federal
Reserve Bank, Medtronics, Motorola, Northrup Grumann, Applied
Physics Laboratory, Hewlett Packard, IDX, Siemens Medical, Gestalt,
Wildcard Systems, Primavera, Yahoo, Conchango, BMC, Lexis-Nexis,
Bentley Systems, Bose, CapitalOne, Federal Reserve Bank,
ClearChannel, Xerox, bwin, Nokia, Motorola, SAP, Ariba, Cisco,
Covad Communications, DoubleClick, Mercury Interactive,
SalesForce.com, Google, TomTom/Teleatlas, Intuit, Electronic Arts,
most game companies, teleradiology, Hangout, Air Force Advanced
Fighter heads up display, Erste Bank, AWACS, Adobe, Nominum,
Hangout, eDialogue, IDX teleradiology, NewsPage, Wildcard
Systems, F4-Networks, Engineering Innovation, Certeon, Allianz
Versicherung, AxonActive, ...
Source: collected
8/8/2012
www.axonactive.vn
26
... Scrum Artefacts
... Scrum Events
... Scrum Team
8/8/2012
www.axonactive.vn
27
... Scrum Team
Stakeholders
Product Owner
Scrum Master
Scrum Team
Team
8/8/2012
www.axonactive.vn
28
... Scrum Team
Product Owner
PO
► Defines the features of the product, decides on release date and content (based on product backlog)
► Is responsible for the profitability of the product (ROI)
► Prioritizes features according to market value
► Can change features and priority at product level
► Accepts or rejects w ork results (delivered product)
► represents the stakeholders and the business
© unbreakablepo.com
8/8/2012
www.axonactive.vn
29
Product Owner
... Scrum Team
Responsible for the ROI and the Product
© unbreakablepo.com
8/8/2012
www.axonactive.vn
30
... Scrum Team
Scrum Master
SM
► Ensures that the team is fully functional and productive
► Enables close cooperation across all roles and functions and removes barriers
► Shields the team from external interferences
► Ensures that the process is followed. Invites to daily scrum, iteration review and planning
meetings, ...
► Enforce timebox
©iStockphoto.com/ zoranmzoranm
8/8/2012
www.axonactive.vn
31
Scrum Master
... Scrum Team
Responsible for increasing
i
Productivity
and for using the scrum framework
©iStockphoto.com/ zoranmzoranm
8/8/2012
www.axonactive.vn
32
... Scrum Team
Team
T
► Cross-functional, seven plus/minus two members (full-time membership; Team based not Project based)
► Selects the iteration goal and specifies w ork results (based on order)
► Has the right to do everything within the boundaries of the project guidelines to reach the
iteration goal
► Organizes itself and the work
► Demos work results to the Product Owner
©iStockphoto.com/mikedabell
8/8/2012
www.axonactive.vn
33
Team
Responsible for delivering the product of each sprint
... Scrum Team
7 +/+/ - 2 member
©iStockphoto.com/mikedabell
8/8/2012
www.axonactive.vn
34
... Scrum Team
Stakeholder, Business Owner, ...
Steakholder
► The Product Owner works with the Stakeholders , represents their interests to the Team
► group of people who have an interest in your product that aren’t directly involved with its creation
► mostly also the customer
► sometimes who defined the business idea
► it can be everybody who is not part of the SCRUM TEAM
8/8/2012
www.axonactive.vn
35
Stakeholder, Business Owner, ...
... Scrum Team
Can support the Scrum team (as a Chicken)
8/8/2012
www.axonactive.vn
36
... Scrum Artefacts
... Scrum Events
... Scrum Team
8/8/2012
www.axonactive.vn
37
www.axonactive.vn
38
... Scrum Events
CYCLE - process SCRUM
8/8/2012
CYCLE steps and cycle
habit and stability
... Scrum Events
To get a potential shippable product increment
8/8/2012
www.axonactive.vn
39
CYCLE steps and cycle
NO changes during the sprint
... Scrum Events
The sprint is save and locked after commitment!
8/8/2012
www.axonactive.vn
40
... Scrum Events
CYCLE scrum artefacts
8/8/2012
www.axonactive.vn
41
... Scrum Events
ARTEFACTS Planning 1 WHAT
Attendees: ScrumMaster, Team, PO
Preparation: PO must prepare the backlog prior to meeting
Goal: Analyze the Product Backlog, Clarification on Backlog item (RISK, VALUE)
Goal: Select potential backblock Items for next sprint based on SIZE
Timebox : max. 4 hours (for a 4 week sprint)
Team / PO: will define SPRINT GOAL
Team: Make suggestions for items
PO: Final decision on what items to work on (will prove the goal again)
Team: Final decision on how much items to work on
8/8/2012
www.axonactive.vn
42
... Scrum Events
ARTEFACTS Planning 2 HOW
Attendees: ScrumMaster, Team
Must be available for answering question: ProductOwner
Goal: define the real issues and order for this sprint
(identifies TASKS, ESTIMATE)
Timebox: max. 4 hours (for a 4 week sprint)
Output: Sprint backlog
Output: Final commitment (proved by PO)
8/8/2012
www.axonactive.vn
43
... Scrum Events
ARTEFACTS Daily Meeting
Attendees: ScrumMaster, Team
RULES
Goal: Synchronize work
Discussion after the daily Scrum
Timebox: 15 minutes
Penalty for being late
Questions:
Same place and time every day
• What have you done since last meeting?
• What will you do before next meeting?
• What is in your way?
8/8/2012
Chickens (listen) and pigs (listen / talk)
Collect Impediments
www.axonactive.vn
44
ARTEFACTS Review Meeting
Attendees: ScrumMaster, Team, PO, Stakeholders
... Scrum Events
Preparation: No more than 1 hour (to be sure that everything is available and run)
Goal: Present the functionality and review it, adjust the requirements
Timebox: 4 hours (for a 4 week sprint)
• Team presents “DONE” functionality and discusses with PO and stakeholders
• Team cannot present functionality that is not “done”
• Product Owner prioritizes backlog accordingly
• LIVE Demonstration
8/8/2012
www.axonactive.vn
45
... Scrum Events
ARTEFACTS Retrospective Meeting
Attendees: Team, ScrumMaster.
(PO should be not for the Team Retrospective)
Timebox: 3 hours (for a 4 week sprint)
Actions
• Do we only have a few actions?
• Are they considered useful?
• Are they implemented?
Goal: Reflect and create actions for improvements
Is “done” extended?
Questions:
• What went well during last sprint
Updating our working agreements?
• What could be improved during last spint
• ScrumMaster facilitates
Do we require:
• Improvements needing action will be added to next sprint • Tasks in the Sprint backlog?
choose always 3 new issues and this three needs to be• improved
Items in the Product backlog?
8/8/2012
www.axonactive.vn
46
Best practice - unofficial ... Scrum Events
ARTEFACTS Releaseplanning Meeting
Release Planning
Whole Backlog
Several
Sprint backlogs
Attendees: PO, the Team and ScrumMaster
will support
Several
Sprints
Meeting timebox: as needed
date
Release cycle: release date time boxed based on fixed date with flexible scope OR fix scope flexible
Release
Goal: get a commitment for a release schedule, see release Burn down and Product Backlog
Best practice - unofficial ... Scrum Events
8/8/2012
www.axonactive.vn
47
ARTEFACTS Releaseplanning Meeting
Release Planning
Whole Backlog
Several
backlogs
Attendees: PO as needed, TeamSprint
and ScrumMaster
Several
Sprints
(PO should be not for the Team Sprint)
Meeting timebox: as needed
Release cycle: release date time boxed based on fixed date with flexible scope OR fix scope flexible
date
Release
Goal: get a commitment for a release schedule, see release Burn down and Product Backlog
8/8/2012
www.axonactive.vn
48
The backlog evolves, and its contents change frequently.
New items are discovered and added to the backlog based on customer and user
feedback.
Existing items are modified, reprioritized, refined, or removed on an ongoing basis.
It will be never fixed.
Grooming is Teamwork
Attendees: PO, the Team and ScrumMaster will support
D etailed
E stimated
E mergent
P rioritised
Meeting timebox: as needed
1. Analyse the customer and user feedback
2. Integrate the learning
3. Decide what to do next sprint
4. Create small stories
5. Get the stories ready (check acceptance criteria)
www.axonactive.vn
... Scrum Team
... Scrum Events
8/8/2012
8/8/2012
Output:
49
... Scrum Artefacts
Best practice - unofficial ... Scrum Events
Backlog Grooming
www.axonactive.vn
50
Best practice - unofficial ... Scrum Artefacts
ARTEFACTS Userstory
High-Level
Initial Story for sprint planning (Formal)
Front side: story
Best practice - unofficial ... Scrum Artefacts
8/8/2012
Back side: acceptance criteria
www.axonactive.vn
51
ARTEFACTS Userstory
High-Level
Initial Story for sprint planning (Formal)
Front side: story
I ndependent
N egotiable (until sprint)
V aluable (for customer)
E stimable
S mall
T estable
8/8/2012
Back side: acceptance criteria
As a <user role>,
I want <goal>
so that <reason>
Can I <acceptance criteria>
www.axonactive.vn
52
Or BDD
Story
Example 1: New lists are empty
Given a new list
Then the list should be empty.
Example 2: Lists with things in them are not empty.
Given a new list
When we add an object
Then the list should not be empty.
Based on Stories
Its also possible
To start
Code
BEHAVIOR DRIVEN
based
Source: http://en.wikipedia.org/wiki/Behavior_Driven_Development
8/8/2012
www.axonactive.vn
53
Userstory why
Main dish
comes with
soup or
salad
and bread.
...
8/8/2012
www.axonactive.vn
...
54
Requirenments
Functional
requirements
Non Functional
requirements
"A requirement specifies a function that a system
or component must be able to perform."
• Business Rules
• Transaction corrections, adjustments, cancellations
• Administrative functions
• Authentication
• Authorization –functions user is delegated to perform
• Audit Tracking
• External Interfaces
• Certification Requirements
• Reporting Requirements
• Historical Data
• Legal or Regulatory Requirements
...
8/8/2012
• Performance –
Response Time, Throughput, Utilization, Static Volumetric
• Scalability
• Capacity
• Availability
"A non-functional
• Reliability
• Recoverability
requirement is a
• Maintainability
statement of how a
• Serviceability
system must behave,
• Security
• Regulatory
it is a constraint upon
• Manageability
the systems
• Environmental
behaviour."
• Data Integrity
• Usability
• Interoperability
...
www.axonactive.vn
55
www.axonactive.vn
56
... Scrum Artefacts
Product Backlog
8/8/2012
... Scrum Artefacts
Product Backlog (concept)
Items at top are more granular than items at the bottom
8/8/2012
www.axonactive.vn
57
www.axonactive.vn
58
... Scrum Artefacts
Product Backlog (concept)
D etailed
E stimated
E mergent
P rioritised
8/8/2012
... Scrum Artefacts
Product Backlog (concept)
8/8/2012
www.axonactive.vn
59
... Scrum Artefacts
Product Backlog (concept)
• One list per product, one product backlog for one team
• List of functionality, technology, issues
• Emergent, prioritized, estimated
• More detail on higher priority items
• One list for multiple teams (this request area product backlogs)
• Product Owner responsible for priority
• Anyone can contribute
• Driven by Business and Vision
• the list is maintained and public posted
8/8/2012
www.axonactive.vn
60
... Scrum Artefacts
Sprint Backlog (concept)
• Issues / Stories with more than 1 or 2 days should be put in smaller tasks
• Team members sign up for tasks, they aren't assigned
• Estimated work remaining is updated daily
• All sprint work is covered there (research, bugs, etc...)
Best practice - unofficial ... Scrum Artefacts
8/8/2012
www.axonactive.vn
61
Sprint Backlog (concept)
Stories are the commitment -> estimation POINTS
Each story can have several Tasks -> estimation in Points / Hours
the task should be not bigger than one day
this tasks are initial tasks
this tasks will discover the work to meet the fix scope of the story commitment
Every estimation is always based on Remaining Time
8/8/2012
www.axonactive.vn
62
... Scrum Artefacts
Sprint Backlog | Kanban
8/8/2012
www.axonactive.vn
63
... Scrum Artefacts
Impediment Backlog
©iStockphoto.com/jalalajalala
Organize and collect the impediments which can not solved during the sprint in one backlog
It is management’s job to remove provide an impediment removal service to the teams
so that they optimize value delivery.
choose always 3 new issues and this three needs to be improved
This is very hard work for Scrum Master
8/8/2012
www.axonactive.vn
64
responsibility
PO (T)
T (PO)
T (PO)
T
T
T
PO / T
8/8/2012
www.axonactive.vn
65
HELPFUL TOOLS
Helps us to stay on track
8/8/2012
www.axonactive.vn
66
adjustments value | The iron triangle
Scope is driven by budget and time in WATERFALL
Scope drives budget and time in TRADITIONAL METHODS
Budget
AGILE
Waterfall
Scope
Scope
Quality
Quality
Time
Budget
Overtime
8/8/2012
www.axonactive.vn
Time
Not on Time
67
adjustments units | time boxed
► ALL Meetings
► Development time (Sprints)
► Release
©iStockphoto.com/RBFried
8/8/2012
www.axonactive.vn
68
adjustments units; long-term productivity
►
►
►
►
no regularly overtime
higher long term productivity
planning of workload with team velocity and points instead of hours
the best team productivity is with around 85% load
Maxw ell Curve
8/8/2012
www.axonactive.vn
69
Plan-Do-Check-Act (PDCA) cycle
Act
Plan
Check
Do
W. Edwards Deming
8/8/2012
www.axonactive.vn
70
... Scrum Theory
three legs of scrum | adapt
8/8/2012
www.axonactive.vn
71
Sprint abnormal Termination
A sprint can be cancelled
by the Product Owner
if the sprint make no sense because of external
influences
by the Team if there is no way to fulfil anything
in the current Sprint
(should be approved by PO)
Start with a new
planning
and review the reasons of the termination
©iStockphoto.com/ Milos Jokic
8/8/2012
www.axonactive.vn
72
ScrumMaster
ScrumMaster
Project manager
Team
Team
Team
Team
ScrumMaster
facilitates
project manager
coordinates
8/8/2012
www.axonactive.vn
73
Best practice - Planning Meeting
The whole sprint
Order, schedule ...
How does a sprint work
Your time is limited at this meetings ...
You will need always a efficient process ...
©iStockphoto.com/ Kriss Russell;
8/8/2012
www.axonactive.vn
74
Best practice - Planning Meeting
PlanningMeeting
8/8/2012
www.axonactive.vn
75
www.axonactive.vn
76
Best practice - Planning Meeting
PlanningMeeting
Best practice - Planning Meeting
Size
8/8/2012
www.axonactive.vn
77
Best practice - Planning Meeting
Size
< 1 or max 2 days
8/8/2012
www.axonactive.vn
78
Best practice - Planning Meeting
MoSCoW
© Wikimedia: Рудаков Владимир
8/8/2012
www.axonactive.vn
79
www.axonactive.vn
80
Best practice - Planning Meeting
MoSCoW
© Wikimedia: Рудаков Владимир
8/8/2012
Must have
Order of one timebox
Best practice - Planning Meeting
MoSCoW
The requirement is essential, key stakeholder needs will not be satisfied if this requirement
is not delivered and the timebox will be considered to have failed. MUST can be
considered a backronum from M inimum U sable S ubse T
Should have
This is an important requirement but if it is not delivered within the current timebox, there is
an acceptable workaround until it is delivered during a subsequent timebox
Could have
This is a nice to have requirement; we have estimated that it is possible to deliver this in
the given time but will be one of the requirements de-scoped if we have underestimated
Won't have
The full name of this category is ‘Would like to have but Won’t Have during this timebox’;
requirements in this category will not be delivered within the timebox that the prioritisation
applies to
Source: www.daily-scrum.com/features/moscow-prioritization
8/8/2012
www.axonactive.vn
81
www.axonactive.vn
82
Best practice - Planning Meeting
customer value
8/8/2012
Best practice - Planning Meeting
Risk
For Risk and Customer Value
The PO should get the double
number as each team member
© Logan Ingalls from South Boston, MA, USA
8/8/2012
www.axonactive.vn
83
www.axonactive.vn
84
Best practice - Planning Meeting
kanban | planning board
8/8/2012
Best practice - Planning Meeting
risk value matrix
8/8/2012
www.axonactive.vn
85
www.axonactive.vn
86
Best practice - Planning Meeting
risk value matrix
8/8/2012
Best practice - Planning Meeting
risk value matrix | get priority
8/8/2012
www.axonactive.vn
87
Best practice - Planning Meeting
Order
Count with steps of 10
You can easy
reorder and
put some
stories
in-between
8/8/2012
www.axonactive.vn
88
Best practice - Planning Meeting
kanban | planning board
8/8/2012
www.axonactive.vn
89
www.axonactive.vn
90
Best practice - Planning Meeting
kanban | planning board
8/8/2012
Best practice - Planning Meeting
get order, check the acceptance criteria
8/8/2012
www.axonactive.vn
91
www.axonactive.vn
92
CYCLE scrum artefacts
Best practice - Planning Meeting
HOW TO ESTIMATE
At the planning meeting
8/8/2012
www.axonactive.vn
93
www.axonactive.vn
94
Best practice - Planning Meeting
estimation
• Quick
• Reliable
• Fun
• Fibonacci – Less argument
• Clarification on the difference
Not on the agreements
• Everybody is involved
Not only dictated by
most-knowledgeable person
8/8/2012
Best practice - Planning Meeting
estimation
Show a picture of planning poker set!
© Wikimedia: Borb (FibonacciBlocks.svg)
8/8/2012
www.axonactive.vn
95
www.axonactive.vn
96
Best practice - Planning Meeting
estimation
~75%
8/8/2012
Best practice - Planning Meeting
estimation | relation
> Relative estimation!
> Reference Story
(everybody should know it and should have the full understanding of this story)
> Points NOT hours! NO UNIT! For a Story item
www.axonactive.vn
8/8/2012
97
(planning meeting)
estimation | relation
2?
Okay, how long does
this story take?
...
8
Zzzzzzh
?????
Idea from: www.crisp.se/planningpoker
8/8/2012
www.axonactive.vn
98
(planning meeting)
estimation | relation
Hmm 2?
...
13 ?
Zzzzzzh
Maybe 40 ?
8/8/2012
www.axonactive.vn
99
(planning meeting)
estimation | relation
?
...
13 ?
Zzzzzzh
?
8/8/2012
www.axonactive.vn
100
(planning meeting)
estimation | relation
Hmm ... 2?
10
? 13
13 !
? 13
8
Okay 13 !
Maybe 40 ?
8/8/2012
www.axonactive.vn
PLANNING POKER
101
®
At the planning meeting
Planning Poker® is a reg. trademark of Mountain Goat Software, LLC.
Sequence of values is (C) Mountain Goat Software, LLC.
8/8/2012
www.axonactive.vn
102
(planning meeting)
estimation | relation
2
8?
Okay, how long does
this story take?
13?
5?
40?
8/8/2012
www.axonactive.vn
103
(planning meeting)
estimation | relation
I thought ... And because
of..... I know that...
Okay, thanks, big
divergence, why?
I done this and ... I got
... My experience... If
I do ..... Because ...
8/8/2012
www.axonactive.vn
104
(planning meeting)
estimation | relation
Ah, yes, i see.... hmmm
Okay, lets play again?
Ah, yes, i see.... hmmm
8/8/2012
www.axonactive.vn
105
www.axonactive.vn
106
(planning meeting)
estimation | relation
8/8/2012
(planning meeting)
estimation | relation
Yes
Yes
Okay, between 5 and 8 Not
such a big convergence.
everybody feel confident with
8?
Yes
Yes
Yes
8/8/2012
www.axonactive.vn
107
www.axonactive.vn
108
(planning meeting)
estimation | relation
Okay, how do you
think about the next
story?
8/8/2012
(planning meeting)
estimation | relation
I have no Idea.
I'm lost with this
story
I need a
break!
I see, there are some
questions, this story is
not clear and we
need a break.
Okay, lets have 5
minutes break
8/8/2012
www.axonactive.vn
109
(planning meeting)
estimation | relation |countries
1
2
3
5
big
Source: www.docondev.com/2010/08/roshambo-estimating.html
8/8/2012
www.axonactive.vn
110
Best practice - Planning Meeting
Sprint Backlog
8/8/2012
www.axonactive.vn
111
Sprint Backlog
Story
Task
If u need you can
create initial TASKS
Can be estimated in
hours
• Tasks / Stories with more than 1 or 2 days should be put in smaller tasks
• Team members sign up for tasks, they aren't assigned
• Estimated work remaining is updated daily
• All sprint work is covered there (research, bugs, etc...)
8/8/2012
www.axonactive.vn
112
Sprint Backlog
Just for getting a higher
responsibility for quality and
testing we make sometimes a
estimation for D evelopment
and one for
T est.
the total points for the first
• Tasks / Stories with more than 1 or 2 days should be put
in smaller
tasks
Story
are 35 points
• Team members sign up for tasks, they aren't assigned
• Estimated work remaining is updated daily
• All sprint work is covered there (research, bugs, etc...)
8/8/2012
113
www.axonactive.vn
Sprint Backlog
This list should be updated
everyday with the remaining
points ...
For each story!
You can do the update at
theindaily
meeting
• Tasks / Stories with more than 1 or 2 days should be put
smaller
tasks
• Team members sign up for tasks, they aren't assigned
• Estimated work remaining is updated daily
• All sprint work is covered there (research, bugs, etc...)
8/8/2012
www.axonactive.vn
114
Best practice - Planning Meeting
COMMITMENT
last step at planning meeting
8/8/2012
www.axonactive.vn
115
www.axonactive.vn
116
Best practice - Planning Meeting
Velocity
8/8/2012
Velocity
One easy guesstimate rule
just 5 minutes for getting the available
working time for the following sprint
8/8/2012
www.axonactive.vn
117
Velocity
e.g three weeks sprint, starting by Wednesday
and a team size of 6 member
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
15 Days
0.5 Review
0.5 Retrospective
1
Planning I/II
0
Boxed days
---------------------------------13 Days left
===================
Don’t forget to count the
Scheduled holidays of
each team member
during this sprint
e.g.
one member takes 1 day
a other member 2 days
Calculate minus 3 days
--------------------------------13 days x 6 member = 78
78 - 3 holidays
= 75
===
8/8/2012
www.axonactive.vn
118
Velocity
You know already:
319 points done (average of the last sprints with same team )
78 working days for a normal sprint
4 velocity per day and person
319 / 78 = 4.09
(round off)
4 points per day and person
1
2
3
4
5
6
7
8
9
10
11
12
----------------------------------13 Days left
====================
working days
75
====================
This mean, we have
75 x 4 = 300
(round off)
13
14
15
8/8/2012
300 points can be commitment
for next sprint
www.axonactive.vn
119
Velocity
You know already:
319 points done (average of the last sprints with same team )
78 working days for a normal sprint
4 velocity per day and person
The current velocity is:
4 velocity
per day and person
8/8/2012
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
www.axonactive.vn
300 velocity
for sprint
120
Velocity
Grooming
Planning 1
Planning 2
1
2
3
4
5
6
7
8
9
10
11
12
Release
Review
13
14
Retrospective
15
Planning 1
Planning 2
Grooming
8/8/2012
www.axonactive.vn
121
www.axonactive.vn
122
Scrum Schedule
8/8/2012
Commitment
©iStockphoto.com/ pixdeluxe;
8/8/2012
www.axonactive.vn
123
www.axonactive.vn
124
The work will start
Backlog for
related teams...
Sprint backlog
8/8/2012
www.axonactive.vn
125
Best practice - Planning Meeting
Story
The story is owned
by the Team!
This only means:
who is currently
working on
5
Could be the
sign of the
verified person
Tai
S
8/8/2012
5
8
www.axonactive.vn
Must
126
Sprint Backlog | Kanban
Now you can add the
committed sprint backlog
direct to the “team board”
(Kanban)
This is the place where
you will have usually your
daily meeting.
8/8/2012
www.axonactive.vn
127
www.axonactive.vn
128
Best practice - Planning Meeting
How can I know our velocity
©iStockphoto.com/ OwnPrice;
8/8/2012
Velocity
Based on the
1.
2.
3.
4.
5.
Velocity
Number of team member
Number of stories
Commitment
1. Story points done
2. Story points remaining*
Working days
You can get a good forecast about the
speed of your team
*is a story started but not finished, must be spitted
and should be re-estimated
8/8/2012
www.axonactive.vn
129
Velocity
you will get information about
productivity and the next
sprint planning will be easier
...
8/8/2012
www.axonactive.vn
130
Velocity
8/8/2012
www.axonactive.vn
131
www.axonactive.vn
132
Daily Meeting
WHERE TO DO?
Daily Meeting
8/8/2012
www.axonactive.vn
133
www.axonactive.vn
134
In front of your team board
8/8/2012
Who is doing what ...
SM
Don’t do it like this!
8/8/2012
SM
www.axonactive.vn
135
www.axonactive.vn
136
Kanban | Team info board
8/8/2012
Kanban | Team info board
8/8/2012
www.axonactive.vn
137
www.axonactive.vn
138
Kanban | Team info board
8/8/2012
kanban | Team info board
8/8/2012
www.axonactive.vn
139
www.axonactive.vn
140
kanban | Team info board
8/8/2012
BURNDOWN
At the daily meeting
8/8/2012
www.axonactive.vn
141
Burndown
Example if you track the daily
burndown in an excel file
This is only useful for
remote
8/8/2012
www.axonactive.vn
142
Burndown
Team 1 “lazy”
10 stories
10 days
100 points commitment
8/8/2012
www.axonactive.vn
143
Burndown
Common mistake 1
We are hiding important information, if we just use one simple
burndown like only for points everyday!
Often it will look quite good but there is no way to get a successful sprint
In total 80% NOT DONE
8/8/2012
www.axonactive.vn
144
Burndown
Team 2 “no Risk”
10 stories
10 days
100 points commitment
8/8/2012
www.axonactive.vn
145
Burndown
Common mistake 2
High risk and big stories at the end....
The combined chart will discoverer this problem
It looks like only 30 points remaining but this two
stories are 50 points. They are not part of the
delivery sprint product.
This mean nearly 50% NOT DONE
8/8/2012
www.axonactive.vn
146
Burndown
Team 3 “progress”
10 stories
10 days
100 points commitment
The big burn up is now
a bit earlier ... time to act
8/8/2012
www.axonactive.vn
147
Burndown
Team 3 “progress”
High risk and big stories at the beginning,
helps to solve problems earlier
....
Even here was a burn up but enough time to act
95% Done of this Sprint
8/8/2012
www.axonactive.vn
148
BURNDOWN
BASED ON REMAINING
At the daily meeting
8/8/2012
www.axonactive.vn
149
www.axonactive.vn
150
Burndown
Important are the
remaining points,
Agile is not interested in
how many points are
already done!
We want know how many
points are left!
8/8/2012
Burndown
Daily meeting
Velocity 4 points per day and personStill not finished as
Story 1 = 8 Points
planned, I need
more time but nearly
finished....
6
4
2
0.5
0.5
0.5
Person 1
8/8/2012
www.axonactive.vn
151
Burndown
Daily meeting
Person 1
4 points per dayPerson
and person
2
Is just tracking Velocity
the
Story
1
=
8
Points
Say how much
working hour...
effort is still
remaining for this
story!
6
4
2
0.5
8
8
6
4
0.5
With this information
we can easier say
something about the
delivery time
And we can catch the
problems much earlier
and can take influence
0.5
Person 1
Person 2
8/8/2012
www.axonactive.vn
2
2
152
Review
www.axonactive.vn
153
Review
The meeting should feature a live demonstration
NOT A REPORT
T
T
ST
T
ST
T
Everybody can join,
Customer should be involved
T
T
The Team will only present FINISHED stories
PO
After demonstration the PO review the commitment made at last planning
And declare which item is DONE (and part of potential shippable)
8/8/2012
www.axonactive.vn
154
Review
The meeting should feature a live demonstration
NOT A REPORT
T
T
ST
ST
• Show Live demonstration
• AVOID PowerPoint
-> show end-user functionality
- Use acceptance test
T
T
Everybody can join,
T
T
The Team will only present FINISHED
Review, consider,
organize, decide,
inspect - Adapt
• Focus on discussion more than on demo
Customer should be involved
• Shared learning rather than reporting
• AVOID long “demo preparation”
preparation ~1hour
stories
to prepare environment
prepare data
make a own schedule
PO
It helps to discover
what the customer
really want
After demonstration the PO review the commitment made at last planning
And declare which item is DONE (and part of potential shippable)
8/8/2012
www.axonactive.vn
155
www.axonactive.vn
156
Product changes
Update backlog:
- With new requirements
- With changed requirements
- With the corrected understanding
Retrospective
www.axonactive.vn
157
Retrospective
The Team will reflect there own process
Facilitated by
ScrumMaster
What went well,
what could be
improved.
SM
Team devises
solution to most
vexing problems
T
T
Last Sprint
T
T
T
T
To solve in next sprint
Choose every sprint three impediment and
This three needs to be solved!
8/8/2012
www.axonactive.vn
158
Retrospective
The Team will reflect there own process
Facilitated by
ScrumMaster
What went well,
what could be
improved.
SM
Team devises
solution to most
vexing problems
TAKE ALWAYS CARE THIS MEETING
T
SCRUM can be only get SUCESS with this meeting.
its one of the most important meeting!
Last Sprint
T
Check previous actions first. If not done, retrospect on them!
T
Only select a couple actions and really DO them.
T
Focus on an constructive attitude.
- “What can WE do”.
T
T
To solve in next sprint
Some hints:
http://www.scrumalliance.org/articles/61-plan-of-action
Choose every sprint three impediment and
This three needs to be solved!
8/8/2012
www.axonactive.vn
159
www.axonactive.vn
160
Impediment backlog
Update backlog:
- The SM will take care this.
- but it doesn't mean that he
need to solve all items
by himself
Product Backlog
∑
8/8/2012
www.axonactive.vn
161
Product Backlog
Maybe the product
owner like it to prepare
it in an excel file... *
But be careful, don't use to many tools,
then u will produce overhand work and
nothing is synchronized.
*the estimation need to be
updated after each sprint
paper will be the most efficient way...
Its always the remaining
estimation
8/8/2012
www.axonactive.vn
162
Product Backlog BurnDown
If we got all stories
estimated, we can keep
track about the product and
make a more realistic
release plan ...
Similar to the daily
sprint burn down we
can get based on the
planning meeting and
the velocity of your
team you can get a
product burn down
8/8/2012
www.axonactive.vn
163
Product Backlog BurnDown
if we update the backlog
careful, it will indicate us: when
we will reach the goal of the
product.
Here it will be after sprint 8
8/8/2012
www.axonactive.vn
164
RESPOSNSBILITY
8/8/2012
www.axonactive.vn
165
www.axonactive.vn
166
Chickens and Pigs
Source: www.implementingscrum.com
8/8/2012
Who is who and where? SCRUMLIES
8/8/2012
www.axonactive.vn
167
Who is who where where? SCRUMLIES
8/8/2012
www.axonactive.vn
168
NOTES / HINTS
Go / no-go
8/8/2012
www.axonactive.vn
169
“undone” work - release sprint
Avoid This!
You will hide the reality and you will not solve problems;
You will get problems!
Undone work contains: Delay & Risk
8/8/2012
www.axonactive.vn
170
“undone” work - the undone unit
Avoid This!
You will hide the reality and you will not solve problems;
You will get problems!
Undone work contains: Delay & Risk
8/8/2012
www.axonactive.vn
171
www.axonactive.vn
172
Secret developer toolbox!
Don’t do it!
Don’t use it!
©iStockphoto.com/Sean Lock
8/8/2012
Definition of Done
a story is defined to be done if we have done:
> checked in to subversion
> Deployment (place should be defined with PO)
- test case
- deployment description ready
- if needed example files
> documented
- technical documentation
- user manuals
- migration notes
- new and noteworthy
> reviewed b another team member (or paired)
code review guidelines are used
- code comments
- naming convention
> successfully build by e.g. hudson
> appropirately tested
- junit tests
- integretaion tests
- automation tests
- manual tests
- code quality, zero bugs
> ready to show a demonstration example
> quality of build release tested and
approved by another team member
- usability
- simplicity
- Function
- integration
- performance
- all exceptance criteria are full filled
8/8/2012
www.axonactive.vn
173
www.axonactive.vn
174
protected sprint
Nino Barbieri
8/8/2012
protected sprint
Source:
8/8/2012
www.axonactive.vn
175
www.axonactive.vn
176
Handmade
8/8/2012
AGILE MANIFESTO
8/8/2012
www.axonactive.vn
177
agile Manifesto
http://agilemanifesto.org/
8/8/2012
www.axonactive.vn
178
agile Manifesto
Chúng tôi phát hiện ra cách phát triển phần mềm tốt hơn bằng cách
thực hiện nó và giúp đỡ người khác làm điều đó. Qua công việc này,
chúng tôi đã đi đến việc đánh giá cao:
Các cá nhân và sự tương tác hơn là quy trình và công cụ;
Phần mềm chạy được hơn là tài liệu toàn diện;
Việc cộng tác với khách hàng hơn là việc đàm phán hợp đồng;
Sự phản hồi với các thay đổi hơn là bám sát kế hoạch.
http://HanoiScrum.net
http://agilemanifesto.org/
8/8/2012
www.axonactive.vn
179
Principles behind the Agile Manifesto
(1) Our highest priority is to satisfy the custom er through early and continuous delivery of valuable software.
(2) W elcom e changing requirem ents, even late in developm ent. Agile processes harness change for the
custom er's com petitive advantage.
(3) Deliver working software frequently, from a couple of weeks to a couple of m onths, with a preference to the
shorter tim escale.
(4) Business people and developers m ust work together daily throughout the project.
(5) Build projects around m otivated individuals. Give them the environm ent and support they need, and trust
them to get the job done.
(6) The m ost efficient and effective m ethod of conveying inform ation to and within a developm ent team is faceto-face conversation.
(7) W orking software is the prim ary m easure of progress.
(8) Agile processes prom ote sustainable developm ent. The sponsors, developers, and users should be able to
m aintain a constant pace indefinitely.
(9) Continuous attention to technical excellence and good design enhances agility.
(10) Sim plicity--the art of m axim izing the am ount of work not done--is essential.
(11) The best architectures, requirem ents, and designs em erge from self-organizing team s.
(12) At regular intervals, the team reflects on how to becom e m ore effective, then tunes and adjusts its
behavior accordingly.
Source: www.agilemanifesto.org/principles.html
8/8/2012
www.axonactive.vn
180
Pair programming
Pair programming is an agile software development technique in which two
programmers work together at one workstation.
One types in code while the other reviews each line of code as it is typed in.
The person typing is called the driver.
The person reviewing the code is called the observer (or navigator[1]). The
two programmers switch roles frequently.
http://en.wikipedia.org/wiki/Pair_programming
http://en.wikipedia.org/wiki/File:Pair_programming_1.jpg
8/8/2012
www.axonactive.vn
181
PROJECT MANAGEMENT
Hints and notes
8/8/2012
www.axonactive.vn
182
Kanomodel
8/8/2012
www.axonactive.vn
183
www.axonactive.vn
184
Project sucess slider
Source: www.mountaingoatsoftware.com/tools/project-success
8/8/2012
scalability ….
- For one customer feature u will need several teams
this will cost additional planning, coordination
handover.... (waste)
- One story is split to several teams
( )
- One customer feature can be created by one team
the dependencies between teams is sharing code
it simplify planning
require: frequent integration
- One story is only related to one team
8/8/2012
www.axonactive.vn
185
scalability ….
1st Sprint planning - together (AREA)
2nd Sprint planning - alone (TEAM)
Sprint loop alone (TEAM)
Product is coming together (everybody)
Review together (AREA)
1st Retrospective alone (TEAM)
2nd Retrospective (everybody)
8/8/2012
www.axonactive.vn
186
scalability ….
SM
SM
SM
SM
SM
SM
SM
SM
SM
SM
SM
SM
SM
SM
SM
SM
SM
SM
8/8/2012
SM
SM
SM
SM
SM
SM
SM
SM
SM
SM SM
SM
www.axonactive.vn
187
www.axonactive.vn
188
cool stuff day
8/8/2012
Self organized teams
Self-directed teams
Traditional organization
Customer-driven
Management-driven
Multi-skilled workforce
Workforce of isolated specialists
Few job descriptions
Many job descriptions
Information to everybody shared
Information limited
Few levels of management
Many levels of management
Whole-business focus
Function/department focus
Shared goals
Segregated goals
Seemingly chaotic
Seemingly organized
High worker commitment
High management commitment
Continuous improvements
Incremental improvements
Self-controlled
Management-controlled
Values/principles based
Policy/procedure based
Source: www.featureteamprimer.org
8/8/2012
www.axonactive.vn
189
organisation
Be aware: Scrum will change the Organisation
Scrum Team
Being able to deliver a product every month will have a rippleeffect through the whole organisation
Source: www.odd-e.com
8/8/2012
www.axonactive.vn
190
Organisation
Scrum will be conflicting with lots of traditional organization roles and
responsibilities:
-
Project manager will disappear?
-
Line manager will change
-
Tester will disappear?
-
Other roles will change...
... Impediment backlog ...
Always remember, this will be a personal change in some persons future and
career!
-
It will be sometimes really difficult and really painful.
Source: www.odd-e.com
8/8/2012
www.axonactive.vn
191
Organisation
Common reasons
for changing Scrum
99.99% of the changes to Scrum itself are because of
not understanding its purpose
or
to hide problems.
Avoid that.
Source: www.odd-e.com
8/8/2012
www.axonactive.vn
192
Good Scrum Smells
• Estimates are updated every day
(by remaining time)
• Everybody is there at scrum on time every day
(penalty for late)
• People offer to help others
• People ask for help
• People present the team with problems and solve them as a team
• work cross functional
(cross testing)
(help to verify other stories, e.g. By sign)
• There is lots of talking and interaction
• Lots of silly bits introduced by the team
8/8/2012
www.axonactive.vn
193
Bad Scrum Smells
• The are
Sprint
requires
a lot
more work than was planned
• Estimates
updated
every
day
Team member
(by•remaining
time) reports the same item more than two days
with
same
or greater
estimates
• Everybody
is the
there
at scrum
on time
everyand
daynobody notices or
(penaltycares
for late)
•
Product
not available for consultation
• People offer to Owner
help others
• Hidden
multiple backlogs
• People
ask foror
help
• Acceptance
the with
status
quo
• People
present the of
team
problems
and solve them as a team
•
No
interaction
outside
of
daily
scrum
• work cross functional
• Definition
(cross
testing) of Done/Acceptance Criteria missing
• Failure
to produce
potentially
shippable
software every sprint
(help
to verify
other stories,
e.g. By
sign)
Distractions
from and
outside
the team
• There• is
lots of talking
interaction
• Lots of silly bits introduced by the team
Source: Original slide - Alan Atlas
8/8/2012
www.axonactive.vn
194
where are the BUGs
© Jon Sullivan (PD-PDphoto.org)
8/8/2012
www.axonactive.vn
195
www.axonactive.vn
196
just start!
8/8/2012
ONLINE?!
This is not such easy and will produce some
overhead work
Mostly only useful for distributed teams
Online tools can not replace a
real board (Kanban) and paper
stories!
8/8/2012
www.axonactive.vn
197
www.axonactive.vn
198
Online tools
Source: www.agilezen.com; axonactive.vn (redmine, mantis)
8/8/2012
just start!
©iStockphoto.com/olm26250
8/8/2012
www.axonactive.vn
199
Starting point
Starting point in your company
1. Get at least one dedicated long-lived permanent
and cross-functional team
2. Define “Done”
3. Make sure all work flows via the Product Owner
4. Keep project managers out
Source: www.odd-e.com
8/8/2012
www.axonactive.vn
200
just start! Sprint 0
1. Setup Team (crossfunctional, Training Scrum)
2. Setup environment
-Software / hardware / Server
-Whiteboard
-Online project management needed?
3. Setup backlog
4. Get experience
5. Get first velocity
6. Negotiate and get DoD ready (approved by PO)
8/8/2012
www.axonactive.vn
201
Disclaimer
This presentation is an ongoing w ork and w ill be updated frequently and improved frequently.
1. Use
This presentation may be used:
By Sebastian Sussmann for AxonActive Vietnam and ECCI
2. Content
The author reserves the right not to be responsible for the whole correctness, completeness or quality of
the information which is provided at this document. If some body will get problems because of using some
information out from this presentation, the author will reject all claim. Because the author can not
guarantee the correct use of all provided information. The author done it with the best of one's knowledge
and belief
This presentation / document is not complete. The author can add and remove and change complete or
partly everything at every time.
3. Copyright
The author intended not to use any copyrighted material for the presentation. For the case it was clear
indicated he provide the copyright and source information at this page to indicate the copyright and the
way of use.
The copyright for any material created by the author and the company AxonActive Vietnam is reserved.
Any duplication or use of objects such as images, diagrams, sounds or texts in other electronic or printed
publications is not permitted without the author's agreement.
4. References:
http://www.s c r um al l ia nc e.o r g/
http://www.s c r um .or g/
http://www.od d- e.c om /
http://www.das s c r um team .c om /
http://www.bo r is g lo ger .c om /
http://www.s o r ec o.c h / / http://ww w.ax onac t i ve. vn
http://www.ag i l e v ietn am .or g/
http://www.to r s te n- ho r n.d e/
http://www.m ounta in goats of t war e .c om /
8/8/2012
www.axonactive.vn
202