Agile projetcs (sizing and estimation)

Editor's Notes

• #8: 569 pages Estimating by Analogy When estimating by analogy, the estimator compares the story being estimated to one or more other stories. When estimating this way you do not compare all stories against a single baseline or universal reference. Instead, you want to estimate each new story against an assortment of those that have already been estimated.
• #9: Why Estimates Estimated are necessary for sizing and approving projects Early estimates are required to calculate ROI, leading to deciding which projects to be selected Early estimates help in determining which piece of work can be done within each release or iteration
• #11: Definition of Ready Moving from Done Done to Ready Ready
• #12: The Agile Team who is going to perform the work is responsible for estimating The team is also committing to the rate of progress they can do according to the approaches to be used and their rate of progress The agile team is responsible to make decisions concerning how the work will be achieved and what amount of work can be done on a certain time frame The person responsible for implementing gets to estimate (xp)
• #13: 569 pages Estimating by Analogy When estimating by analogy, the estimator compares the story being estimated to one or more other stories. When estimating this way you do not compare all stories against a single baseline or universal reference. Instead, you want to estimate each new story against an assortment of those that have already been estimated.
• #14: Story Points How long a user story will take (effort) Influenced by complexity, uncertainty, risk, volume of work, etc. Relative values are what is important A login screen is a 2 A search feature is an 8 Example: I can read book in a month and you read it in a week ( 1 point), if we got a book with double the size so we both agree that it’s 2 points Traditional software teams give estimates in a time format: days, weeks, months. Many agile teams, however, have transitioned to story points. Story points rate the relative effort of work. It may sound counter-intuitive, but that abstraction is actually helpful because it pushes the team to make tougher decisions around the difficulty of work. Here are few reasons to use story points: Dates don’t account for the non-project related work that inevitably creeps into our days: emails, meetings, and interviews that a team member may be involved in. Dates have an emotional attachment to them. Relative estimation removes the emotional attachment. Each team will estimate work on a slightly different scale, which means their velocity (measured in points) will naturally be different. This, in turn, makes it impossible to play politics using velocity as a weapon. Once you agree on the relative effort of each story point value, you can assign points quickly without much debate.  Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time.  Estimate smarter, not harder No individual task should be more than 16 hours of work. (If you're using story points, you may decide that, say, 20 points is the upper limit.) It’s simply too hard to estimate individual work items larger than that with a high degree of confidence. And that confidence is especially important for items at the top of the backlog. When something is estimated above your team's 16-hour (or 20-point) threshold, that's a signal to break it down into more granular pieces and re-estimate. For items deeper in the backlog, give a rough estimate. By the time the team actually begins to work on those items, the requirements may change, and your application certainly will have changed. So prior estimates won’t be as accurate. Don’t waste time estimating work that is likely to shift. Just give the product owner a ballpark figure she can use to prioritize the product roadmap appropriately. Relative Sizing and Story Points It’s easier for the human brain to compare 2 items instead of just guessing an estimate What is the size of an Orange? what’s the size of and Orange compared to a watermelon and a grape? It may be more difficult to estimate how long a particular feature will take to develop but it is relatively easy to guess if it is more or less complex than other features A story point is a metric used to estimate the difficulty of implementing a given item A story point is and abstract measure of the effort required to implement the item Ideal Time The time needed to complete a given task as if there is no interruptions In an 8 hours work day, it assumes that all the eight hours are available for work, and all other distractions and non-project work are eliminated Simple and easy to use, yet it can be easily understood by and explained to all stakeholders The main drawback is that the measure of ideal time varies from one person to another based on their own skills and competencies Planning in a Week The XP solution is to accept more risk in the plan by having bigger stories. Write stories you can estimate in terms of ideal programming months instead of ideal programming weeks How long something will take if: It’s all you work on No one interrupts you And everything you need is available
• #15: Example: I can read book in a month and you read it in a week ( 1 point), if we got a book with double the size so we both agree that it’s 2 points
• #16: 569 pages Estimating by Analogy When estimating by analogy, the estimator compares the story being estimated to one or more other stories. When estimating this way you do not compare all stories against a single baseline or universal reference. Instead, you want to estimate each new story against an assortment of those that have already been estimated.
• #25: Planning Poker is played in a way that “influence between the participants” is minimized, therefore a more accurate estimation result is produced Usually teams used a modified version of the Fibonacci Sequence: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. to reflect the uncertainty in estimating larger items A high estimate usually means that the story is not well understood in detail or should be broken down into multiple smaller stories