This presentation describe
What is the need for user stories in Agile project?
What is a story?
What is criteria for a good story?
What are not stories?
Prerequisite? Knowledge of Scrum and it’s terms
Software requirements is a communication problem.Software Engineer != Construction.Building software is side effect of discovering the customer’s problems.
The communication problem is between those who want the software and those who build the software
If either side dominates the business loses.
The functionality and dates are mandated with little regard for reality or whether the developers understand the requirements.
… technical jargon replaces the language of business and developers lose the opportunity to learn from listening.
We need a way of working together so that resource allocation becomes a shared problemProject fails when the problem of resource allocation falls too far to one side
We cannot predict a software schedule. Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain (Wikipedia). Estimation is prediction NOT planning. Typical first estimate is off by factor of 4 0.25x to 4x. They should be naturally realigned as we gather more information during the project.
Human beings in general are bad at absolute estimates. They are good at relative estimation.
We make decisions based on the information we have, but do it often
Rather than making one all-encompassing set of decisions, we spread decision making across project
Card – Stories are traditionally written on note cards. Cards may be annotated with estimates, notes, etc
Conversation – Details behind the story come out during conversations with product owner
Confirmation – Acceptance tests confirm the story was coded correctly
Stories that are big are called EPIC. They can potentially be broken down into smaller stories. Epics are listed in the product backlog for future sprints / iterations.
A collection of related user stories
If the requirements are written down then At best the customer will get what was written. Customer may make lot of assumptions while writing the requirements.
Stories support and encourage iterative development. Encourage deferring the detail until you have the best understanding of what you really need.
Intentionally left blank.Think what points might go in this slide
A user story is request for valuable stuffPromise for future conversationIn scrum it goes into product backlog item.
Identifies who the user is, what they want to do and why?
This mnemonic helps determining whether a story is acceptable or not.
If there is lot of dependency it might suggest we are breaking work in horizontal layers (in tiers – Database, db layer, business logic, UI)Agile methodology suggest to breaking work in vertical layers (slice through tiers)If not independent, it make product backlog difficult to manage multiple layers of dependency.If dependency is unavoidable, then prioritize dependent stories after the stories they depend on.Or use mocking architecture, decouple dependency.
Story should be request for value.Should not dictate what they want.Advantage is it will avoid biased opinion Eg: By how many runs will England win against India. This mean we are assuming that England will win.Too much detail turns user story into contract which is taking away self-organization capability of scrum team.
Identifying value is key part of writing the story.Everything in scrum is value driven.
Common reasons why they’re not estimableLack domain knowledgeCan discuss with business people and learnLack technical knowledgeCan spike on the story to learn more about itTwo stories, one for the spike one for the real workStory is too big – cannot commit to big stories.Sometimes useful to write the epic to be a placeholder for some glossed over part of a system.Pulled from thin air estimate!Or break it down.
Small stories are easier to estimate.A story that is too big to do in single sprint is an “EPIC”
Cross cutting concerns: compliance with corporate needs. External regulations.