Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


User Stories... Unleashed

No description

Sarah Wren

on 5 April 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of User Stories... Unleashed

Developing Agile
Requirements with
User Stories

User Stories... Unleashed
What is a User Story?
Project Requirements
& Communication Problems
Tests that convey and document the details
The Process
Why move to User Stories over a Requirements Document?
Writing User Stories
Gathering Stories
the process of gathering requirements; think of the mental image of requirements being captured in a fishing net behind a boat.
User Role Modeling
Identify all the possible users of the system.
To be successful, a project relies on information
from the heads of very different people.
There must be a balanced mix between the business and the technical team
Decisions have to be made based on the information at hand.
Rather than making all decisions at the outset of the project, Agile spreads the decision making across the entire project.
The Card
The Conversation
The Confirmation
A written description of the story used for planning and as a reminder
Conversations about the story that serves to flesh out the details
What question did you always ask when you were assigned a term paper in school?
It is better to have more stories than stories that are too big. Stories that are too large are called epics
waterfall process has all requirements established at the beginning
analyze them
design a solution
code the solution
and finally test the solution
This process has customer and/or user involvement at the beginning to write requirements and at the end to for acceptance testing, but they disappear in between
customers and users are involved throughout the entire project.
User Story Process
Why do customers write the stories?
1. Each story should be written in the language of the business
2. The customer team is in the best position to describe the behavior of the product
User Stories...
1. Emphasize verbal rather than written
2. Are comprehensible by both customer team and development team
3. Are the right size for planning
4. Work for iterative development
5. Encourage deferring detail until you have the best understand of what is really needed
As much as possible, try to avoid introducing dependencies between stories, this can lead to prioritization and planning problems
Stories are negotiable, they are not written contracts or requirements that the software must implement. Stories are short descriptions of functionality, with the details being negotiated in a conversation with the development team and the customer.
Each story must carry a value for either the user, customer or the developer. The best way to ensure that the story is valuable to the customer or user is to have the customer write the story. Most customers begin writing stories once they get comfortable with the concept that it is a reminder to talk later rather than a formal requirement.
It is important for the development team to be able to estimate the size of a story or the amount of time it will take to turn the story into working code. There are three common reasons why a story may not be estimable:
1. Developers need a general understanding of the story; if not, they should discuss it with the customer
2. The developers do not understand the technology involved
3. The story may be too big.
Some stories are too big some can be too small, and some can be just right. An epic, the ultimate determination of an appropriate sized story is based on the team, its capabilities, and the technologies in use.
Stories must be written so as to be testable. Successfully passing its tests proves that a story has been developed correctly.
Guidelines for good stories
Percentage growth of job postings containing the phrase “Agile software”. The last six years have seen a massive 1750% growth in the number of Agile jobs advertised on the site.
an initial set of user roles
the initial set
Consider creating a “
” for each user.
A persona is an imaginary representation of a user role; i.e, a name and a description.
Extreme Characters
such as a drug dealer, the Pope, elderly
1. Different sized nets used for different sized requirements
2. First pass might get all the big ones
3. Leave the smaller ones for later
4. Requirements, like fish, mature and some die
5. Skill plays a factor in finding the requirements –
a skilled requirements trawler will know where to look for requirements, an unskilled trawler will waste time.
User interviews:
one of the main keys to this is selecting the right set of users. Using open-ended questions is better than a yes-no.
these are useful when you need answers from a large number of users to specific questions. Questionnaires do not lend themselves to follow up questions.
Observing users interacting with your software is a great way to pick up insights.
Story-writing workshops:
This is a meeting that includes developers, users, the product customer, and other parties who can contribute to writing stories. Participants write as many stories as possible, priorities are not assigned at this time. This can actually lead to a low-level prototype of the system,
Questions to ask to help identify missing stories are:
 What will the user most likely want to do next?
 What mistakes could the user make here?
 What could confuse the user at this point
 What additional information could the user need?
Goal Stories
what is the user really trying to do?
Write closed stories
a closed story finishes with the achievement of a meaningful goal, providing a sense of accomplishment
List constraints
Constraint cards are not estimated and scheduled but they are identified as reminders
Size the story to the horizon
Focus your attention on areas that need the most attention. This means paying attention to things happening in the near future
Keep the UI out as long as possible
Do not mix requirements with solution specifications.
Include user roles in the stories
writing stories in this format keeps the right user in the forefront of the developers mind.
Customer writes the stories
responsibility for writing the stories resides with the customer and cannot be passed to the developers
Don’t forget the purpose
the main purpose of a story card is to act as a reminder to discuss the feature. Keep these reminders brief.
I saw an interview one time with a fighter pilot,” Yost recalled, “and they asked him: 'If your plane was crashing, and you had 15 seconds until you hit the ground, what would you do?’
The fighter pilot gave what I thought was a great answer.
He said, `I’d consider all of my options for the first 13 seconds; then I would act.’ That makes sense to me. You take your time, if you have time, to consider all of your options. Then you make a decision.
Unfortunately, we often miss the mark on estimating.
Why do projects
Is it the project...?
the estimates...?
failure to estimate is the reason that projects fail. We really don’t know how to estimate.
Projects fail because they rely too heavily on the estimates
Traditional project plans involve using
calendric estimates
For every part of the solution, the developers must

the when it will be ready
They need to know when they will
, how much time it will take to deliver the work, and how much time will be “wasted” on
Estimating the development effort is difficult enough, but predicting the
total amount of time
that will be spent not developing is near
Clearly, a different method of doing things is necessary; Agile methodologists came up with different estimation techniques to reduce the chances and ramifications of failure.
Agile Estimating Techniques
Three most common Agile estimations
T-Shirt Size estimations are coarse grained separation of requirements into buckets of
This estimate is of course extremely easy to make intuitively, and of course insufficient as a basis for project planning due to its low resolution, but is often
sufficient for the purpose of pricing single features
(example scenario might be when required to give a customer a
cost estimate
for some
custom feature
in the system).
very large
Ideal Time estimates are similar to calendric estimates in that they involve high resolution predictions of the effort involved in developing a feature.
The difference is that ideal estimates are made while
ignoring all surprises and interferences
The question that ideal estimates answer is ...
“How much time will it take to develop a solution, assuming you work on nothing else, and nothing else disturbs you."
Taking the unknowable impediment factor out of the equation improves the accuracy of the estimates, but you can’t simply substitute ideal time for calendric time because the unknown impediments still do exist, and the fact remains that humans aren’t good at making absolute estimates, with no point of reference. In Scrum,
Ideal Hours
are often used to estimate the effort of completing
, which should be short, simple and straightforward.
Story Points are a radically different method of estimating development effort. With story points you do not go out and say how much work something is, in and of itself, but rather state how the
to develop one component
to the effort of developing another.
These estimates are much easier to make, and
surprisingly accurate
we are much better at comparing things than estimating them
Of course, comparisons and relationships have
no unit of measure,
and thus can’t be used to establish a timeline. At least not in the normal sense.
In Scrum,
Story Points
are usually used to estimate the effort of completing
user stories
(hence the name).
Units of Effort Completed
Velocity is thus ...
As an example: a team that regularly completes an average of 70 units of Effort in a two week Sprint has a Velocity of 70 Units of Effort per Sprint, or is simply stated as just 70.
The simple path is to use Observed Velocity.
Units of Effort your Team completes in a typical Sprint
There are two things of primary interest to us in our calibration. They are:
Calibrating Velocity
1.The Friction or consistent forces that are a constant drag on productivity and reduce Project Velocity.
2.The Variable or Dynamic Forces that decelerate the project or team members and cause the Project Velocity to be irregular.
Optimizing both of these factors prior to Calibration will improve the stability of your Velocity calculation. As the Velocity is the basis for many of the metrics we use in Agile and Scrum, it is important to have a predictable Velocity.
“Every object will remain at rest or in uniform motion in a straight line unless compelled to change its state by the action of an external force.” Forces that do not propel your project will slow it down. By minimizing the forces that slow down your project, you reduce the “Friction” that reduces your Project Velocity. Less friction means higher Velocity and greater productivity.
Newton's First Law States:
In Software development, there are countless forces that can affect the Velocity of your team.

Team composition
: Are the right people with the right skills on the team.

Changes to your processes: Agile methods, build, release, testing, etc…

Environmental factors:
Interruptions, noise, poor ventilation, poor lighting, uncomfortable seating and desks, inadequate hardware or software, etc…

Team dynamics:
Some team members may not play nicely with others.
Newton's Second Law States:
“The acceleration of an object as produced by a net force is directly proportional to the magnitude of the net force, in the same direction as the net force, and inversely proportional to the mass of the object.”
The more consistent and predictable the force, the more consistent your Velocity will be.
Unnecessary acceleration and deceleration not only wastes energy and slows down your team, it also introduces variability. The variations in Velocity make your predictions more difficult. To put it simply: The more you allow your team is influenced by Dynamic Forces and things that change their ability to focus on their work, the more variability there will be in their Velocity (productivity). This variability makes your forecasts less accurate. Some examples include:
Team changes: Adding member, losing members, changing roles and responsibilities.
New tools: Introduction of new development tools, database technologies, languages, etc… require learning, and reduce Velocity until learned.
Vendor defects: Defects in third party tools and software requiring developer workarounds eat into productivity and Velocity.
Responsibilities outside of the project: Team members assuming additional responsibilities outside of the project. Shifting between projects can have a dramatic effect on productivity.
Personal issues: Colicky baby at home, personal health, family dynamics, etc…
Stakeholders: Stakeholders may not be responsive to requests for information from the developers or tester and thus create delays. They may also have unreasonable expectations of the team.
Unclear requirements: Lack of clarity or detail in requirements cause unnecessary churn and rework.
Changing requirements: New project specifications might require skills that are non-existent or weak in the team. Acquiring the skills, either by introducing new team members, or by an existing team member acquiring the skills will impact productivity.
Relocation: Moving the team to a new physical location upsets the rhythm and impacts their Velocity.
By observing your Velocity averaged over three Sprints, and leaving the effects of Dynamic Forces in your Velocity calculations, you will automatically be developing a Velocity baseline that is biased to implicitly include a Dynamic Force compensation weighting.
With three Sprints behind you, take the average Velocity across all three Sprints. This is your Team Velocity. By reducing Friction and minimizing unnecessary Velocity changes prior to Calibration, you have optimized the individual and team Velocities. Over the course of the project, and assuming there are no significant factors introduced such as losing a team member, you should observe a very stable Velocity for the duration of the project.
"Never make predictions, especially about the future"
--Yogi Berra.
T-Shirt Sizes
"This magnitude, 8.2, is not the large earthquake that we were expecting in this area," said Simons. "We're expecting a potentially even larger earthquake. It could be tomorrow. Or it could come in 50 years."

- Mark Simons, a geophysicist at Caltech in Pasadena, California.
April 1, 2014 - Regarding the earthquake in Chile
Full transcript