PMI Agile Certified Practitioner
Chapter 5.
Universidad de Guadalajara
Ingeniería de Software I
Equipo:
Medina Galvan, Luis Humberto
Flores Belmares, Paris
Ortega, Sandra
Jiménez Mendoza, Luis Antonio
Rodríguez, Gerardo
Tools for Sizing and Descomposing
User Story
the three C's
Comunication
Card
Conversation
This refers to the customers confirmation that the history has been implemented correctly
Its just a token that represents the requirement for planning purposes
The characteristics of an efective user story
Independent
Negotiable
Valuable
Estimatable
Small
Testable
Ideally we want to be able to reprioritize an develop in any order thats why its better if they are independent
The team should be able to discuss user stories with the product owner and make trade-offs based on cost and functionality
If we cannot determine the value of a feature the we should question why is even part of the project
We have to be able to estimate the effort a feature is going to take
If the user story is small, its gonna be easier to estimate the amount of effort its development is going to take. also is going to be way easier to fix if it goes wrong. small means around 4 to 40 hours
Having testable user stories is important for tracking progress… among other things obviously
User Story Backlog
This is
A visible master list for all the functional and nonfunctional that the project requieres
Prioritization of the user story backlog
Uses
Guiding the teams priorities
Planning tool for managing iterations and releases
Helps the team manage change requests
Helps the team manage the risk remediation effort with features development
Helps the stakeholders coordinate the project
Keeps every one working towards the agreed goal
Refining the backlog
Its the process of keeping the backlog updated and accurately prioritize. Helps agile projects stay flexible to customer's needs
Involves
Progressively adding more adding more details
Adjusting the estimates and priorities of the backlog`s items
Adding new work
Removing items that are not longer important
Types of Changes that the backlog may need
Add new stories
Existing stories may need to be removed
Existing stories may need to be reprioritize
Existing stories may need to be resized
Relative Sizing and story points
Its a more accurate way of estimating the amount of that needs to be done. It uses a relative unit called story point
By relative sizing, it means that if you think that one feature will take you the twice as much effort you give to that feature 2 story points and the other one you give it one
Story points are typically based on the Fibonacci Series, which is a natural occurring progression to describe how things grow
Guidelines for using story points
The team should own the definition of their story points
Story points should be all inclusive
We Shouldnt have to add any extra time for testing or refactoring, instead our story points should include all the known activities needed to complete the task.
The point sizes should be relative
When disaggregating estimate, the total dont need to match
If we need to decompose the tasks needed to complete a user story, the sum of the smaller task`s story points dont need to match to the original one
Complexity, work effort and risk should all be included in the estimates
Best practices for estimating user stroies
Allow us to change our minds whenever we have new information about a story
Works for both epic and smaller user storys
Doesnt take a lot of time
Provides useful information about our progress and our and the work remaining
Is tolerant to imprecision in the estimate
Can be used to plan releases
Agile planning concepts
The details for each story are communicated via conversation
Is
Valued - based descomposition
Timeboxing
Ideal time
Decomposing requirements
How long a task will take if all the peripheral work and distractions are removed.
High Level Plannig
how to
Slicing the Stories
Is a fixed - duration period of time in which a defined set of activities is done.
There are two ways
Slicing Compound Stories
Iteration Planning
The iteration planing process
1. Discuss the user stories in the backlog
2. Select the user stories for the iteration
3. Define the acceptance criteria and write the acceptance tests for the stories
4. Break down the user stories into tasks
5. Estimate the tasks
Iteration Planning Summary
Selecting the User Stories
Use Actual Results to Refine Estimates
Defining the Acceptance Criteria and Writing the Acceptance Tests
Estimating the Tasks
Estimate Velocity for the First Iteration
need to
Gather the team, look at the backlog
And ask
Which of the top-priority stories in the backlog for this release can we commit?
Estimate ranges
The total points for these stories become our initial velocity estimate
this means
Breaking down any stories that are too large to be completed within one iteration
Slicing Complex Stories
is
A compound story includes other independent stories within it
but
It can't be completed in one iteration
One really big or complicated story; it doesn't include sub-stories.
Release and Iteration Planning
Types of iterations
Spikes
Fast failure
Release Planning
Iteration 0
is
An optional iteration that we can use to set the stage for our development efforts
Iteration H
We have it because
We need another effort after the deliverable is accepted to prepare it for release
Development iterations
It begins once
the preparatory work has been completed
Are
A key tool that agile teams use to head off problems and resolve them as early as possible
Divided in
Risk-Based Spike
Architectural Spike
requieres
Consist in
A backlog that freshly prioritized by the product owner.
Consist in
Investigate and reduce or eliminate an issue or threat to the project.
Checking whether the approach the team hopes to use will work for the project
A goal for the iteration
We reach this condition when
If none of the approaches we try are successful
It consist in
the remaining funds and resources from the project can now be directed to other projects that are awaiting resources.
Break down requirements into smaller chunks of work
Value-Based Analysis
Process of assessing and prioritizing the business value of work items and then planning accordingly
Progressive Elaboration
Agile Discovery
Adaptive Planning
Agile vd Non-Agile Planning
Principles of Agile Planning
Evolution and elaboration of agile project plans in contrast with an up-front, traditional approach to project planning
Process of adding more detail as new information emerges
The only way we can be successful on such projects is to plan to replan
We select
User stories that the customer has indicated are high priority and that we believe can be delivered within the iteration
We do this to
Determine which stories will be done in which iterations for the upcoming release
each
User story
needs
Clear acceptance criteria
Is done in
Are
A meeting in which all the stakeholders are represented
Tailor processes to the project's characteristics
Update the plan based on the project's priorities
Ensure encompassing estimates that account for risk...
Manage expectations...
Use appropriate estimate ranges to reflect the level of ...
Engage the team and the customer in planning
Base projections on completion rates
Plan at multiple levels
Factor in diversions and outside work
They are...
Explicit statements of how the customer will define "done" for each story
will create
More detailed bottom-up estimates to schedule the work
Key ways
Agile planning is less of an up-front effort, and is instead done throughout the project
Midcourse adjustments are the norm
Trial and demonstration uncover the true requirements, which then require replanning
The team elicits requirements from the stakeholders and ranks them
to
to better judge our true progress and estimate the remainder of the project
Daily Stand-Ups
Provide
An early warning system for issues
Keep
Everyone focused on the agreed-upon scope and iteration goal
Are
timeboxed to 15 minutes