Más contenido relacionado La actualidad más candente (20) Similar a Improving the User Story Agile Technique Using the INVEST Criteria (20) Más de Luigi Buglione (20) Improving the User Story Agile Technique Using the INVEST Criteria1. 23° International Workshop on Software
Measurement (IWSM) and 8th International
Conference on Software Process and Product
Measurement (MENSURA)
Ankara (Turkey) - October 23-25, 2013
Improving the User Story Agile Technique Using the INVEST Criteria
Luigi Buglione
Alain Abran
www.eng.it
2. INVEST Grid
Goals of the presentation
1. Discuss the estimation issue as typically dealt with in
the Agile Project Management (APM) context
2. Introduce Mike Cohn’s 6 INVEST criteria for
evaluating a User Story (US)
3. Propose a refinement – the INVEST Grid – for a more
quantitative evaluation, to better balance the set of US within
a Sprint
2
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
3. ETS - GELOG
At a glance
gelog.etsmtl.ca
gelog.etsmtl.ca
3
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
5. INVEST Grid
•
Introduction
•
Agenda
Key Issues:
– The Agile Manifesto (15 years later…)
– Some basic questions
1. Sizing Units
2. Historical Data
3. Requirements
•
INVEST: Grid & Process
•
Lessons Learned from Experience
•
Conclusions & Future Works
•
Q&A
5
– The INVEST Grid
– The INVEST Process
– Definitions, Level of granularity
– Estimation by experience/analogy, Limited attention to test coverage
– Agile Project Management (APM) concepts
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
6. A bit of humour…
URL : http://www.enagility.com
Introduction
6
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
7. Introduction
The Agile Manifesto (15 years later...)
agilemanifesto.org
agilemanifesto.org
http://goo.gl/3p6ky0
http://goo.gl/3p6ky0
7
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
8. Introduction
Some basic questions...
Are agile estimates based on objective assumptions (e.g.
sizing units)?
Are such estimates feasible and repeatable?
How are requirements managed and validated?
Which best practices are in place? Which standards?
Source : Buglione L. & Abran A., Improving Estimations in Agile Projects: issues and avenues, Proceedings of the 4th
Software Measurement European Forum (SMEF 2007), Rome (Italy), May 9-11 2007, ISBN 9-788870-909425, pp.265-274,
URL: http://www.dpo.it/smef2007/papers/day2/212.pdf
8
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
9. INVEST Grid
•
Introduction
•
Agenda
Key Issues
– The Agile Manifesto (15 years later…)
– Some basic questions
1. Sizing Units
2. Historical Data
3. Requirements
•
INVEST: Grid & Process
•
Some Lessons from Experience
•
Conclusions & Future Works
•
Q&A
9
– The INVEST Grid
– The INVEST Process
– Definitions, Level of granularity
– Estimation by experience/analogy, Limited attention to test coverage
– Agile Project Management (APM) concepts
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
10. Key Issues
Results from a Root-Cause Analysis (RCA)...
The 3 main issues from a RCA to improve agile estimations...
1) Sizing Issues
Story Points (SP): estabished locally & impacted by local conditions not repetable, they
estimate the effort (not the size) for an US
The typical “logical chain” is: Q T C
1. Determine the Quantity/ies according to attributes to be sized with their units “sizing”
1+ attributes
2. Based on history: determine Productivity (Q/T), possible to determine the working time
(T), both as Effort (E) as well as Duration (D)
3. According to T (E, D) and knowing costs models (fixed+labour costs), possible to
determine the project/activity Costs (C)
2) Historical Data
In real life any estimation comes from historical data, even if not formalized
(‘experience’)
Since ICT project should be in a middle way between ‘real life’ and ‘rocket science’,
why is it so hard to collect project historical data at the project closure phase?
Workaround (while waiting to collect your own data) access an external repository,
also for benchmarking purposes (e.g. ISBSG, PROMISE)
3) Requirements
FUR + NFRs (see ISO 25010 for a product ‘quality’ model)
Need to analyze in depth NFRs: often ‘hide’ a relevant amount of effort, not apparently
visible to estimators or thought as ‘implicit’ underestimation & litigation between
parties, because of variance between estimates and actuals
10
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
11. Introduction
Key Issue – Dealt with (all) Requirements
US Title
Implementation Priority
Relative
Productivity
/Estimation
Functional
Test
High Level
FUR
Functional Req
(FUR)
Non-functional
Reqs (NFR)
Org/Project related
Reqs
11
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
12. INVEST Grid
•
Introduction
•
Agenda
Key Issues
– The Agile Manifesto (15 years later…)
– Some basic questions
1. Sizing Units
2. Historical Data
3. Requirements
•
INVEST: Grid & Process
•
Some Lessons from Experience
•
Conclusions & Future Works
•
Q&A
12
– The INVEST Grid
– The INVEST Process
– Definitions, Level of granularity
– Estimation by experience/analogy, Limited attention to test coverage
– Agile Project Management (APM) concepts
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
13. INVEST
INVEST – From the Criteria to the Grid
•
Need for Evaluating Requirements in Agile contexts
•
Make INVEST criteria more quantitative
13
“INVEST”: 6 criteria from Mike Cohn for evaluating each US, i.e. qualitative
checklist before approving it in the ‘Planning game’ between the Product Owner
(customer rep.) & Scrum master (provider’s PM)
I – Independent
N – Negotiable
V – Valuable
E – Estimable
Source : Cohn M. User Stories Applied: In Agile Software Development, Chapter 2:
Writing Stories, Addison Wesley, 2004, URL: http://goo.gl/zN2jg
S – Small
T - Testable
The INVEST Grid – next slide - tries to satisfy that need
Create your own definitions over an ordinal scale (e.g. 0-3 as in ISO 14598)
Fill cells as in a maturity model for each criterion
Customer & Provider have to jointly evaluate the achieved level
US will move into production & will be assigned to an iteration/Sprint only when
the agreed thresholds for the 6 criteria will be achieved
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
14. INVEST
The INVEST Grid
0
1
2
3
Poor /Absent
Fair
Good
Excellent
User Stories should be
as independent as
possible
The start of construction
of a US is tied to
the completion of at
least one other US
The completion of a US
hinders the start of
construction of at least
one other US
The US is fully
independent, and it can
be realized and released
with any constraint
N – Negotiable
User Stories should be
"open", reporting
any relevant details as
much as possible
The US contains enough
detail to be a technical
specification (Design
phase), leaving no room
to negotiate any element
The US is written with
enough detail to be a
functional specification
(Analysis phase), leaving
no room to negotiate any
element
V – Valuable
User Stories should pro
vide value to end users
in terms of the solution
The functional part (F) of
the US does not contain
all the functionalities
requested by the
customer
E – Estimable
Each User Story must
be able to be
estimated in terms
of relative size
and effort
S – Small
Each User
Story should be
sufficiently
granular, and
not defined at too high
a level
The US shows only its
functional (F) part, filled in
by the customer, but
without sufficient detail to
allow the provider to fill in
the Q/T parts
The US is very large, and
cannot be completed
within a Sprint
The functional (F) part of
the US expresses mostly
qualitative (Q) and
technical (T) requirements
about the system, and
needs to be more
developed in terms of
functional requirements
The US shows only its
functional (F) part, filled in
by the customer, but
validated with the provider
The US can contain any
constraint, but its release
can be constrained by the
completion of at least one
other US
The US is written with
informative content
defining a User
Requirement in a
consolidated manner, yet
shared between Customer
and Provider
The functional (F) part of
the US expresses mostly
the functional
requirements requested
by the Customer, but also
includes qualitative (Q)
and technical (T)
requirements
The US has been
completed by the provider
with respect to Q/T
issues, but still needs to
be validated jointly with
the customer
The size of the US is such
that it can be completed
within a Sprint, jointly with
other US, but it is too
small to create overhead
about the Testing phase
INVEST
Description
I –
Independent
T – Testable
14
Each User Story must
be formulated in an
effort to stress useful
details for
creating tests
The US does not
include tips about
Acceptance Tests
The US is very large, and
can be completed within a
Sprint, but cannot
accommodate the
creation/delivery of other
US
The US includes a formal
indication of Acceptance
Tests, but yet to be
completed
The US is written with the
informative content typical
of a high-level need,
allowing feedback
between customer and
provider
The functional (F) part of
the US correctly
expresses only the
functional requirements
requested by the
customer
All the useful parts of the
US (F/Q/T) are shown,
allowing the effort need to
size and estimate it, and
validated by both parts
The size of the US is such
that it can be completed
within a Sprint, jointly with
other US, ensuring an
appropriate balance
between development
and testing activities
The US includes an
indication of completed
and validated
Acceptance Tests
The US includes an
indication of
Acceptance Tests which
are complete, but yet to
be validated
Source : Buglione L., Meglio Agili o Veloci? Alcune riflessioni sulle stime nei progetti XP, XPM.it, February 2007, www.xpm.it
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
15. INVEST
The INVEST Grid – Target Profile (example)
0
1
2
3
Poor /Absent
Fair
Good
Excellent
User Stories should be
as independent as
possible
The start of construction
of a US is tied to
the completion of at
least one other US
The completion of a US
hinders the start of
construction of at least
one other US
The US is fully
independent, and it can
be realized and released
with any constraint
N – Negotiable
User Stories should be
"open", reporting
any relevant details as
much as possible
The US contains enough
detail to be a technical
specification (Design
phase), leaving no room
to negotiate any element
The US is written with
enough detail to be a
functional specification
(Analysis phase), leaving
no room to negotiate any
element
V – Valuable
User Stories should pro
vide value to end users
in terms of the solution
The functional part (F) of
the US does not contain
all the functionalities
requested by the
customer
E – Estimable
Each User Story must
be able to be
estimated in terms
of relative size
and effort
S – Small
Each User
Story should be
sufficiently
granular, and
not defined at too high
a level
The US shows only its
functional (F) part, filled in
by the customer, but
without sufficient detail to
allow the provider to fill in
the Q/T parts
The US is very large, and
cannot be completed
within a Sprint
The functional (F) part of
the US expresses mostly
qualitative (Q) and
technical (T) requirements
about the system, and
needs to be more
developed in terms of
functional requirements
The US shows only its
functional (F) part, filled in
by the customer, but
validated with the provider
The US can contain any
constraint, but its release
can be constrained by the
completion of at least one
other US
The US is written with
informative content
defining a User
Requirement in a
consolidated manner, yet
shared between Customer
and Provider
The functional (F) part of
the US expresses mostly
the functional
requirements requested
by the Customer, but also
includes qualitative (Q)
and technical (T)
requirements
The US has been
completed by the provider
with respect to Q/T
issues, but still needs to
be validated jointly with
the customer
The size of the US is such
that it can be completed
within a Sprint, jointly with
other US, but it is too
small to create overhead
about the Testing phase
INVEST
Description
I –
Independent
T – Testable
15
Each User Story must
be formulated in an
effort to stress useful
details for
creating tests
The US does not
include tips about
Acceptance Tests
The US is very large, and
can be completed within a
Sprint, but cannot
accommodate the
creation/delivery of other
US
The US includes a formal
indication of Acceptance
Tests, but yet to be
completed
The US is written with the
informative content typical
of a high-level need,
allowing feedback
between customer and
provider
The functional (F) part of
the US correctly
expresses only the
functional requirements
requested by the
customer
All the useful parts of the
US (F/Q/T) are shown,
allowing the effort need to
size and estimate it, and
validated by both parts
The size of the US is such
that it can be completed
within a Sprint, jointly with
other US, ensuring an
appropriate balance
between development
and testing activities
The US includes an
indication of completed
and validated
Acceptance Tests
The US includes an
indication of
Acceptance Tests which
are complete, but yet to
be validated
Source : Buglione L., Meglio Agili o Veloci? Alcune riflessioni sulle stime nei progetti XP, XPM.it, February 2007, www.xpm.it
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
16. INVEST
The INVEST Process
Not only the Grid,
related Process
but
also
a
As for “INVEST” criteria - 6 steps:
1. Determine the US type – some
US could only be about NFR
(beginning/end of iteration/Sprint)
2. Fill the FUR – typical US elicitation
3. Fill/complete NFRs - (not all the
needed details about NFRs could be
present from the 1st version; e.g. ISO
25010)
4. Apply the INVEST Grid –
evaluate the ‘whole’ US (FUR+NFR)
with the 6 criteria but as in the grid
5. Ok or change FUR? – Go/No-Go
for closing the US writing and
estimation
6. Allocate US to a Sprint – if
everything is OK, according to an
agreed ‘profile’ for the 6 criteria (0-3
values), US can be deployed
16
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
17. INVEST Grid
•
Introduction
•
Agenda
Key Issues
– The Agile Manifesto (15 years later…)
– Some basic questions
1. Sizing Units
2. Historical Data
3. Requirements
•
INVEST: Grid & Process
•
Some Lessons from Experience
•
Conclusions & Future Works
•
Q&A
17
– The INVEST Grid
– The INVEST Process
– Definitions, Level of granularity
– Estimation by experience/analogy, Limited attention to test coverage
– Agile Project Management (APM) concepts
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
18. Some lessons learned
Experience – Attention Points
•
Definitions
•
Level of granularity
•
Estimation by experience/analogy
•
Limited attention to proper test coverage vs requirements
•
APM (Agile Project Management) concepts
18
Realignment of definitions of working items & NFR between customers/providers
Impact on the ‘Small’ criterion
Be consistent in the way to define granularity e.g. ‘elementary process’
‘Manage’ CRUD/CRUDL (Create-Read-Update-Delete-List)
Impact on the ‘Small’ criterion
SP are not repeatable, because set up on local basis Experience + Analogy
Risk to understimate some ‘hidden’ req’s, in particular on the NFR side
Need of historical project data each iteration/delivery could be a ‘mini-project’ to be
coordinated into a wider (high/level) project/program
Attention to the Testable criterion goal: reduce the CONQ by introducing the proper
number of test cases
Look at the right/feasible test coverage threshold
Burndown chart vs Earned Value (absolute) time tracking, not only the deliverable
production/deployment as a progress criterion
The INVEST Grid can help to rethink the Requirements Elicitation phase determine
the right ‘quantities’ to be produced and the related project schedule
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
19. INVEST Grid
•
Introduction
•
Agenda
Key Issues
– The Agile Manifesto (15 years later…)
– Some basic questions
1. Sizing Units
2. Historical Data
3. Requirements
•
INVEST: Grid & Process
•
Some Lessons from Experience
•
Conclusions & Future Works
•
Q&A
19
– The INVEST Grid
– The INVEST Process
– Definitions, Level of granularity
– Estimation by experience/analogy, Limited attention to test coverage
– Agile Project Management (APM) concepts
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
20. INVEST Grid
Conclusions & Future Works
•
Agile Estimations
•
Requirement Management & the INVEST Grid/Process
Estimations in the typical Agile contexts: often based on qualitative approaches
The introduction of techniques/approaches more quantitative-oriented could improve
estimates, reducing the estimation error
Need to maintain the known ‘agile’ way, but introducing new ways than actual
Requirements are ‘key’ need to be complete from several viewpoints
INVEST is a known acronym and series of 6 criteria for evaluating User Stories
(US)...but it is still a quantitative way
The INVEST Grid introduces the ISO 4-levels ordinal scale for rating each criteria
determining a ‘profile’ against an agreed predefined target goal: make US complete
as much as possible but looking at more criteria at the same time
The INVEST Process is a 6-step process giving guidance about the interplay between
customer and provider for achieving the best possible combination of USs per
iteration/sprint
Next Steps
Refine & tailor definitions across the 4 levels for the 6 INVEST criteria
Obtain empirical feedback from various industry domains
...try & see!
All models are wrong. Some models are useful.
All models are wrong. Some models are useful.
(George Box, Mathematician , , 1919-2013)
(George Box, Mathematician 1919-2013)
20
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
21. Lessons Learned...
URL : www.dilbert.com
INVEST Grid
21
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
22. INVEST Grid
Q&A
İlginiz için teşekkürler !
Thanks for your attention !
22
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it
23. INVEST Grid
Our Contact Data
Luigi
Buglione
Engineering.IT/ET
S
Alain
Abran
ETS Montréal
alain.abran@etsmtl.ca
luigi.buglione@eng.it
23
IWSM-MENSURA 2013 – October 23-25, 2013
© 2013 Luigi Buglione & Alain Abran
www.eng.it