Subido por Yamile Cimino Viñales

Agile+Estimation+Notes

Anuncio
Agile Estimation
Notes
Estimation Fundamentals
Velocity vs Commitment Based Planning
Estimation Best Practices
When to Re-Estimate
Estimation Time-frames
Estimation Techniques
Relative Estimation
Estimation Troubleshooting
Estimation Fundamentals
1. An “Agile Estimate” is a measure of the effort involved in completing a piece of work.
2. “By “effort”, we mean a) amount of work b) complexity of work & c) uncertainties involved.
3. An estimate is not a target or a commitment.
4. Estimation is analytical & unbiased while planning is a biased, goal-seeking process
5. Estimation and planning should ideally be kept separate to keep estimation unbiased
6. The primary goal of estimation is to allow a team to set good targets
7. Research has shown that a +20% gap between estimates & targets are hard to achieve
Estimation Best Practices
8. Estimation will only work if the team members are open & honest with each other
9. The whole team should participate in estimation
10. Estimation relies on a clear “Definition of Ready” and “Definition of Done”
11. Especially in early stages where project uncertainty is high, estimate using a range (A to
B) or a confidence level (A with X% confidence)
12. Don’t use a linear estimation scale. Instead use a Fibonnaci sequence, or a Modified
Fibonnaci sequence
13. Rely on your teams current velocity numbers when estimating & planning, and don’t rely
on a projected future velocity
Estimation Time-frames
14. A project is at risk if a plan extends well beyond a planner's horizon & does not include
opportunities for the planner to make adjustments
15. A progressive elaboration of plans works best in agile environments
16. Agile teams do planning in different time-frames
17. Most agile teams do daily planning via a 15 minute “daily scrum”
18. Iteration planning usually looks 1 to 4 weeks out
19. Release planning focuses on supporting upcoming releases
20. Product planning is driven by the Product Owner, and considers how the product needs to
evolve
21. Portfolio & strategic planning are usually performed outside the Agile team
Relative Estimation
22. A relative estimate does not measure using “time units” but an “arbitrary unit”
23. A story point is a measure of effort to complete a user story that is relevant only to a
specific team i.e. 1 story point for team A cannot be compared with 1 story point for team B
24. Story points work well because they
a. Are agnostic of individual skill levels
b. Speed up the estimation process
c. Remove emotional attachment from estimation
d. Reduce unhealthy competition between teams
25. An “ideal day” assumes a) no multitasking b) all resources are available and c) no
interruptions
26. Velocity is the amount of work a team can complete in an iteration
27. Focus factor = actual velocity / available days
Velocity vs Commitment Based Planning
28. Velocity based planning looks at past results and takes a formulaic approach to determine
how much work a team should pick up in an upcoming iteration
29. Commitment based planning relies on the team using “gut feel” and making a commitment
on how much work they should pick up in an upcoming iteration
30. Velocity based planning is easy to justify and works well for long term planning but not as
well for shorter term planning
31. Commitment based planning empowers the team, and can result is greater team
dedication, but does not work as well for long term planning
When to Re-Estimate
32. A story that has not been picked up by development can be re-estimated at any time.
33. A story that is currently in development should generally not be re-estimated as this will
undermine the team's velocity calculations.
34. Bugs discovered that are unrelated to the current iteration can be estimated.
35. Bugs discovered that are related to the current iteration are not estimated, but are
included in the estimation for the related story.
36. Any investigative work (spikes) are usually not estimated, but time-boxed.
37. At the end of an iteration, for partially completed stories, re-estimate work remaining if that
story will be moved back into the Product Backlog i.e. not picked up immediately in the
upcoming iteration.
Estimation Techniques
38. Planning poker encourages “independent thinking” within Agile teams.
39. In Planning Poker, each team member receives a deck of 13 cards with values ?, ∞, 0, ½,
1, 2, 3, 5, 8, 13, 20, 40 and 100. During estimation...
a. Each team member places their selected card face down on the table.
b. Team members all reveal their estimates (cards) at the same time.
c. Differences are discussed, task breakdowns are done as needed until the team arrives
at an agreement.
40. Planning Poker can also be done with distributed teams, using tools like Pointing Poker.
41. T-shirt sizing uses sizes ranging from “XS, S, M, L, XL”.
42. The Bucket System uses a “divide and conquer” approach to estimate a large number of
backlog items in a short period of time.
43. Silent Estimation is optimized for speed, and involves teams performing estimations
silently, with only stories that have disagreements being discussed.
44. The 3 point estimation considered the “Optimistic”, “Likely” & “Pessimistic” outcomes to
triangulate an estimate
Estimation Troubleshooting
45. Estimation is difficult because:
a. Teams often operate in an environment of high uncertainty.
b. Team members have biases such as “planning fallacy” which results in a bias towards
optimism, and “anchoring” which creates a bias towards initial estimates.
46. A user story is not a requirement. It is a short, informal statement that focuses on the end
user and facilitates a conversation within the team. It helps drive clarity and enables better
estimation.
47. A good user story is targeted to a specific persona, is not overly prescriptive (don’t define
the how), and includes acceptance criteria to define the boundaries of the story.
48. Multi-tasking results in a) burnout b) mistakes & c) lack of creativity
49. Acknowledge uncertainty by a) not making early promises b) iterating often and c) learning
how to negotiate with stakeholders
50. A stable agile team has dedicated members who ideally focus on 1 product
Descargar