Send the link below via email or IMCopy
Present to your audienceStart 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.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
The Estimation Process
Transcript of The Estimation Process
Estimating ideals days
Get Prepared for the Planning Meeting!
Review the backlog
Sprint & Planning
Common errors when planning
And the retrospective?
Velocity & Estimates
Tips For Accurate Estimates
When Estimating is Difficult
"In Developers we trust"
The black art.
Estimating: estimating the [resources, time, size] required to develop a [user story, feature, or requirement
Planning: putting the estimates together to formulate a project plan and schedule
Velocity is a measure of a team’s rate of progress.
Velocity is calculated by summing the number of story points assigned to each user story that the team completed during the operation.
We assume that the team will produce in future iterations at the rate of their past average velocity.
The story being estimated is the only thing you’ll work on
Everything you need will be on hand when you start
There will be no interruptions
Create stories with enough information to start the work and estimate it
No new stories should be added to the sprint
If a new story is added something with the same effort should be removed from the sprint
The product owner and the team should agree on what is a story and what is a defect
Review the backlog
Prioritize stories (Product Owner)
Identify technology issues
Identify blocking issues
Identify duplicate stories
Identify related stories
User interaction designers . . .
Moderator (usually the product owner or analyst) reads the description and answers any questions
The Dev team will have to:
• Complete current stories
• Fix Product issues
• Fix defects from past sprints
• Do the review meeting to show the stakeholders the work done during the sprint
Should be planned as a sprint
Plan the production release date
Plan the code freeze date
Plan the Testing dates
Monitor the sprint
Do stand ups
Keep mingle updated so it reflects the real progress of the project
Find blocking issues, change estimates
Inform the product owner when there is a change in the scope
• Add production issues as defects
• Add new stories as defects
• Do work without creating a story or defect
• Do not update the status of the work
• Do not follow the progress of the team
• Do not prepare the review meeting
• Do not do the retrospective
The review meeting is the part of the sprint
It closes the current iteration
Show only completes stories in the QA environment
So, take the time to prepare the stories to show to the customer
This effort is included in the velocity of the team
The customer is expecting to see the results of the sprint
Your project plans are also too important to be disrupted by the slightest provocation
Know every sprint if you're
speeding up or slowing down
• Estimate in terms of ideal engineering days (story points), not calendar time
• Use velocity to determine how many story points the team can finish in an iteration
• Use iteration slack to smooth over surprises and deliver on time every iteration
• Use risk management to adjust for risks to the overall release plan
• Sometimes you will need more information to make an accurate estimate. In this case, make a note on the card. If you need more information from your customers, write "
" (for "unanswered questions") in place of the estimate.
• If you need to research a piece of technology further, write "
" in place of the estimate and create a spike solution story
Programmers should be the only ones estimating stories
If the programmers understand the requirements and are experts in the required technology, they should be able to
estimate a story in less than a minute
If the programmers need to discuss the technology, or if they need to ask questions of the customers, then estimating may take longer.
Don´t forget that...
• The Dev team creates the tasks after the stories are selected for the current iteration
• Analyze if any information is missing to create all the tasks and contact the product owner if necessary
• Create tasks for the needed work of every story
• Calculate the amount of work needed in hours for every task
• Estimate engineering tasks in ideal hours rather than ideal days.
• When you think about the estimate, be sure to include everything necessary for the task to be "done done"—testing, customer review, and so forth.
• The lead should see if the amount of work calculated fits in the current sprint
Common errors during the sprint
Use this meeting to talk about the issues of the sprint
What worked? Didn't work? What to improve? Keep doing?
Review the velocity of the team and the estimation
Do not take into account the time for meetings, vacations, days off, etc.
Do not prioritize stories
Stories without enough information to estimate
Do not use the available information to estimate the velocity
Do not plan for the release
Do not plan for research stories
Do not review the stories before the planning
Prod Release Planning
Iteration Plan Estimation
Release Plan Estimation
How to start?
Choose a medium-size story and assign it a “5”
Estimate other stories relative to that
•Twice as big
•Half as big
•Almost but not quite as big
•A little bit bigger
•0, 1, 2, 3, 5, 8, 13, 20, 40, 100
Avoid creating big stories
how long a task takes if there were no interruptions
Supporting current release
Velocity – how many estimation units get completed by a team in a single iteration?
Velocity corrects estimation errors
Since all user stories are estimated relative to each other . . .
It’s the velocity that should change, not each story point estimate for future releases
Include all players on the development team (but less than 10 people overall):
1. Each estimator is given a deck of cards, each card contains a valid lid estimate.
Power of 2 ––1,2,4,8,16,321,2,4,8,16,32
2. Story is read and discussed briefly
3. Each estimator privately selects a card that reflects their estimate.
4. Cards are turned over for all to see.
5. Discussion takes place
6. Re Re-estimate to try to get convergence.
Define rules for adding stories and defects to the current sprint
Everyone in the team should agree on this
What is a story?
What is a defect?
Create stories for the required work
Create the Release candidate
Update data bases
Bug fixing in the Release candidate
• Allow time for bug fixing, perhaps allocate an entire iteration
• Don’t start a new iteration until the RC is ready to go to production
Code changes and Verification on QA RC
•There should be no code changes on the release candidate unless you need to fix defects for the release.
•After the release candidate is created the QA team should verify the stories
•The product owner should give the sign off to go to production
Velocity relies upon a strict iteration timebox. To make velocity work, never count stories that aren't "done done" at the end of the iteration. Never allow the iteration deadline to slip, not even by a few hours.
Velocity tends to be unstable at the beginning of a project. Give it three or four iterations to stabilize. After that point, you should achieve the same velocity every iteration, unless there's a holiday during the iteration.
Use your iteration slack to ensure that you consistently meet your commitments every iteration.
You can have accurate estimates if you
All of the programmers should participate in estimating.
At least one customer should be present to answer questions
Once the programmers have all the information they need to make an estimate
If the suggested estimate doesn't sound right, or if you don't understand where it came from, ask for details
Alternatively, if you're a programmer, provide your own estimate and explain your reasoning.
The ensuing discussion will clarify the estimate
When all of the programmers confirm an estimate, write it on the story
If the team makes estimates as a group, programmers will automatically synchronize their estimates within the first several iterations
The Estimation Process
If the programmers don't understand the technology, however, immediately create a spike story and move on.
One common cause of slow estimates is inadequate customer preparation. To make their estimates, programmers often ask questions the customers haven't considered. In some cases, customers will disagree on the answer and need to work it out. Here you can:
Discuss briefly the issue with the customers, come to a decision, and return
Write "??" in place of the estimate and move on to the next story. The customers then work out the details at their own pace, and the programmers estimate the story later.
Expect the customers to be unprepared for programmer questions during the first several iterations. Over time, they will learn to anticipate most of the questions programmers will ask.
Programmer inexperience can also cause slow estimating. If the programmers don't understand the problem domain well, they will need to ask a lot of questions before they can make an estimate. As with inadequate customer preparation, this problem will go away in time.
Scope Creep and Rework
Scope Creep: new requirements that were never allocated for in the estimate were estimate
Rework: Doing work more than once because client couldn’t make up their mind
Agilist accept these as a fact of life, but accept they are still require effort
Keep track of out of scope and rework items
Every item that is added to your backlog qualify it as in scope, rework or out of scope
How much information to estimate?
Some programmers try to figure out all the details of the requirements before making an estimate. However, only those issues which would change the estimate by a half-point or more are relevant. It takes practice to figure out which details are important and which you can safely ignore.
This sort of over-attention to detail sometimes occurs when a programmer is reluctant to make estimates. A programmer who worries that someone will use her estimate against her in the future will spend too much time trying to make her estimate perfect rather than settling on her first impression.
Programmer reluctance may be a sign of organizational difficulties or excessive schedule pressure, or it may also stem from past experiences that have nothing to do with the current project. In the latter case, the programmers will usually come to trust the team over time.
To help address these estimation issues, ask leading questions. For example:
Do we need a customer huddle on this issue?
Should we mark this "??" and come back to it later?
Should we make a spike for this story?
Do we have enough information to estimate this story?
Will that information change your estimate?
We've spent five minutes on this story. Should we come back to it later?
Help address the estimation
It's almost a law of physics: customers and stakeholders are invariably disappointed with the amount of features their teams can provide.
Sometimes they express that disappointment out loud. The best way to deal with this is to ignore the tone and treat the customers' questions as honest requests for information
Challenging questions for Developers
· When the customer ask
"Why does it take too long?
"Resist the immediate urge to defend yourself and your sacred honor, pause a moment to collect your thoughts, then list the issues you considered when coming up with the estimate.
Suggest options for reducing the cost of the story by reducing scope.
· Your explanation will usually satisfy your customers. In some cases, they'll ask for more information. Again, treat these questions as simple requests.
· If there's something you don't know, admit it, and explain why you made your estimate anyway.
· If a question reveals something that you haven't considered, change your estimate.
Challenging questions -> Professional answers
Politely but firmly refuse to change your estimates when pressured
Be careful, though: the questions may cause you to doubt your estimate. Your initial, gut-feel estimate is most likely correct.
Only change your estimate if you learn something genuinely new.
Don't change it just because you feel pressured.
As the programmers who will be implementing the stories, you are the most qualified to make the estimates.
Be polite, but firm:
I'm sorry you don't like these estimates. We believe our estimates are correct, but if they're too pessimistic, our velocity will automatically increase to compensate. We have a professional obligation to you and this organization to give you the best estimates we know how, even if they are disappointing, and that's what we're doing.
How to Improve Your Velocity
Your velocity can suffer for many reasons.
How to improve your velocity?
Pay Down Technical Debt
Rather than stopping work to pay down technical debt, fix it incrementally
Improve Customer Involvement
To improve your velocity, make sure that a customer is always available to answer programmer questions.
Support Energized Work
Tired, burned-out programmers make costly mistakes and don't put forth their full effort. Shield the programmers from organizational pressure and consider instituting a no-overtime policy.
Offload Programmer Duties
Find ways to excuse programmers from unnecessary meetings, shield them from interruptions, and have somebody else to take care of organizational bureaucracy such as time sheets and expense reports
Provide Needed Resources
Computers, office, phones, solve technical issues
Add Programmers (Carefully)
Velocity is related to the number of programmers on your team, but unless your project is woefully understaffed and experienced personnel are readily available, adding people won't make an immediate difference.
How Much Slack?
The amount of slack you need doesn't depend on the number of problems you face. It depends on the randomness of problems.
If you always experience exactly 20 hours of problems in each iteration, your velocity will automatically compensate. However, if you experience between 20 and 30 hours of problems in each iteration, your velocity will bounce up and down. You need ten hours of slack to stabilize your velocity and to ensure that you'll meet your commitments.
These numbers are just for illustration. Instead of measuring the number of hours you spend on problems, take advantage of velocity's feedback loop
If your velocity bounces around a lot, stop signing up for more stories than your velocity allows. This will cause your velocity to settle at a lower number that incorporates enough slack for your team.
On the other hand, if your velocity is rock solid, try reducing slack by committing to a small extra story next iteration
How to Introduce Slack
Schedule no work on the last day or two of your iteration. This would give you slack, but it would be pretty wasteful.
A better approach would be to schedule useful, important work that isn't time-critical—work you can set aside in case of an emergency. Paying down technical debt fits the bill perfectly
Rather than doing the bare minimum necessary to keep your head above water, be generous in refactoring and cleaning up technical debt in existing code.
Every iteration, look for opportunities to make existing code better. Make this part of your everyday work.
Paying down technical debt directly increases team productivity
As you fix technical debt, focus on fixes that make your current work easier. Don't go looking for technical debt that's unrelated to stories you're currently working on.
Dedicated research time is an excellent way to encourage learning and add additional slack into your iterations.
When Your Iteration Commitment Is At Risk
Research time and paying down technical debt are important tasks that enhance your programmers' skills and allow them to deliver more quickly.
However, if your iteration commitments are at risk, it's okay to set these two tasks aside temporarily in order to meet those commitments
Don't Cross the Line
Slack is a wonderful tool. It helps you meet your commitments and gives you time to perform important, non-urgent tasks that improve your productivity.
Be careful, though. If you rely on slack to finish your stories in every iteration, that time isn't really slack—it's required.
If you work overtime, cancel research time, or don't pay down any technical debt for two or three iterations in a row, you've over-committed and have no slack.
Congratulate yourself for delivering on your commitments anyway. Now add slack by reducing your velocity.
We are done
Thank you for attending the course