Why We Need a Granularity Concept for User Stories...RQ3: Is it possible to control EID by splitting...
Transcript of Why We Need a Granularity Concept for User Stories...RQ3: Is it possible to control EID by splitting...
Why We Need a Granularity Concept for User Stories
Olga Liskin, Raphael Pham, Stephan Kiesling, Kurt Schneider
Software Engineering Group
University of Hannover, Germany
User Stories
• Heart of Agile Methods • Describe small user-oriented parts • Guide daily work – Help clarify requirements – Show what to implement next – Help with planning & monitoring progress
Olga Liskin -‐ User Story Granularity 2
How can we make good user stories?
Which guide daily work Which help to communicate with customer
Olga Liskin -‐ User Story Granularity 3
Many things on how to write good User Stories But how about what we put in? Difference:
Olga Liskin -‐ User Story Granularity 4
As a Basketball Coach I want to buy Sports gear to equip my
team.
As a Basketball Coach I want to be able to select all different sizes I need of a specific
product I chose
Granularity
„extent to which a larger entity is subdivided“ (Wikipedia)
Olga Liskin -‐ User Story Granularity 5
Important CharacterisJc of User Stories
Let‘s invesJgate that!
Should be taken more into account when working
with User Stories
Granularity
Olga Liskin -‐ User Story Granularity 6
clear vs.
vague
concrete vs.
abstract
small scope vs.
large scope This is it
Expected Implementa.on Dura.on (EID)
EsJmated Jme (in days) that a developer or pair will need to
implement a story
Research Questions
Goal: Characteristic which helps improve User Stories
Olga Liskin -‐ User Story Granularity 7
RQ1: Is EID easy to measure?
RQ2: Which actual EID values do user stories in current projects have?
RQ3: Is it possible to control EID by splitting user stories?
RQ4: Is EID a relevant factor for user stories?
Survey
• Sent out to 600 GitHub-Users • 53 usable answers – 41 participants reporting about industrial
projects they work on – 12 participants reporting about private projects
Olga Liskin -‐ User Story Granularity 8
RQ1 – Easy to measure?
• 49% consider implementation duration when rating a user story
• 55% claimed they could assess implementation duration if necessary
• Over-/underestimation:
Olga Liskin -‐ User Story Granularity 9
RQ2 – Actual EID Values
19%
24%
25%
19%
13%
a few hours 1 day 1-‐3 days 4-‐5 days > 1 week
Olga Liskin -‐ User Story Granularity 10
Distribute 100 points: which implementaJon duraJons to User Stories you typically work with have (3400 points total)
If your user story is 3 days long, it means
the customer doesn‘t understand for 3 days what‘ s
going on!
RQ2 – Actual EID Values
Olga Liskin -‐ User Story Granularity 11
In more detail: Percent of the quesJonees who have allocated x or more points to certain story sizes
RQ2 – Actual EID Values
Olga Liskin -‐ User Story Granularity 12
In more detail: Percent of the quesJonees who have allocated x or more points to certain story sizes Half of our
quesJonees say: 30% or more of our stories take more
than 4 days
RQ3 – Splitting Stories to Control EID
Olga Liskin -‐ User Story Granularity 13
Could a user story with the given EID be split into smaller stories?
RQ3 – Splitting Stories to Control EID
Olga Liskin -‐ User Story Granularity 14
Could a user story with the given EID be split into smaller stories?
However, a problem emerged:
At some point, a story gets so small that it has no more value for
the customer
RQ4 – EID relevant?
Olga Liskin -‐ User Story Granularity 15
Larger Story leads to ....
Communication
One has to change more details aaerwards
it takes longer until one can gather feedback about this story
more probable that one develops more than what was expected
it is harder to meet thecustomer's requirements
RQ4 – EID relevant?
Olga Liskin -‐ User Story Granularity 16
Smaller Story leads to ....
Tangibility
our estimation of how long the story will take is more precise
I can estimate better how many code parts I will have to touch in order to implement it
I can estimate better with how many other developers I will have to talk
it will less often grow unexpectedly in time/complexity
Small esJmaJon because of lacking
knowledge
Take granularity into account when doing
planning!
Conclusions & Outlook
Olga Liskin -‐ User Story Granularity 17
If a User Story is larger than one day, you should split it!
If a User Story has a very small es.ma.on,
be careful
Small step towards finding out about user
story granularity
Concrete values?
Customer‘s perspecJve?
More Outlook
User Stories relatively fine grained Sometimes we need coarsely grained requirements artifacts Be part of the User Story story! I‘m looking for experiences & opinions: [email protected] @o_liskin
Olga Liskin -‐ User Story Granularity 18