Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Agile Estimating and Planning by Mind Map: Agile Estimating and Planning
0.0 stars - reviews range from 0 to 5

Agile Estimating and Planning

The Problem and The Goal

Purpose of Planning

Why Do It?, a quest for value, Answer the question: What should we build?, Reducing RIsk, Discussions during estimating raise questions that expose dark corners of a project, Reducing Uncertainty, Over time the team is getting smarter, about, the product, the technologies, themselves as a team, Goal is to build the right product, not the initially thought up product, Supporting Better Decision Making, Will the project miss the market window?, Will the project be profitable?, Are key personnel required (Architect) that may not be available?, How many developers do we need to make the project work in time but not cost too much to not be worth it?, All of these are trade off decisions that need to be made throughout the project and agile estimating can help support better answers, Establishing Trust, Build to reliable estimates leads to, reliable delivery and estimates to the users, sustainable development pace for developers, Conveying Information, A plan conveys expectations, does not guarantee an exact set of features on exact dates, Estimated date of completion is not useful alone, estimate with a plan conveys information about the realism of the estimates

What Makes a Good Plan?, One that stakeholders find sufficiently reliable that they can use it as the basis for making decisions, Early on, may be "product can be released in the 3rd quarter rather than the 2nd, with approximately xa described set of features", Later, this will need to be more precise to continue to be useful for decision making, Marketing can decide on when to prepare marketing materials, schedule advertising campaign, allocate resources to assist with upgrading key customers, Time estimate has to be somewhat predictive, otherwise it's not reliable to make decisions from, 1-2 months off still may be useful, and if updated regularly the change should have been made clear well before being late, 6 months off is probably not useful

What Makes Planning Agile?, Balances the effort and investment in planning with the knowledge that we will revise the plan through the course of the project, Focused more on the planning than on the plan, Encourages Change, A plan we are not only willing, but also eager to change, change means we have learned something new, Results in plans that are easily changed, Change could be, scope of features, add people to the project, drop features, changing dates, this is not required just an option, Is spread throughout the project, Planning is spread evenly across the duration of a project

Why Planning Fails

Stats, Nearly 2/3rd of projects significantly overrun their cost estimates (Lederer and Prasad 1992), 64% of the features included in products are rarely or never used (Johnson 2002), The average project exceeds its schedule by 100% (Standish 2001)

Planning Is by Activity Rather Than Feature, We need to focus on user value/features instead of activities, Activities are defined as: Due database thing, due middle tier thing, test thing etc, Traditional schedule is created for review, Review is looking for forgotten activities rather than missing features, Activities Don't Finish Early, "Work expands so as to fill the time available for its completion" - Parkinson's Law, Gold-plating often occurs to fill the allotted time, Why finish early when you may be accused of padding estimates or being piled on with more work, Activities are not independent, Independent - duration of one activity does not influence the duration of another, building a house, time to excavate the basement is independent of the time to paint the walls, Software is often not independent, One task taking longer probably implies the rest will take longer then initial estimate as well, Lateness is passed down the schedule, Because activities are often sequential and not feature based, lateness on the first activities means lateness is passed to all activities, Need to focus on features so lateness is limited to a feature and has limited impact, it shouldn't add months of delays to all features

Multitasking Causes Further Delays, Misconception of multitasking increasing productivity, driven by, if 1 task is blocked, you should have 2 others to work on, loading developers 100% load is like loading a highway to 100% capacity, No one can make any progress, Need to eliminate blockers, find ways to be more independent of real blockers and continue to make as much progress as possible on features

Features Are Not Developed by Priority, Assumptions in plans are all identified activities will be completed., This means order is usually done for convenience of the team, Then at the end of the project, it's a relatively haphazard list of features that are completed, some features are dropped entirely when they had the most identified value

We Ignore Uncertainty, Users will change their minds, refine opinions or come up with new needs, Estimates on activities are seen as precision times and not the estimates they truly are, Not all activities will be identified up front for even the expected features delivered, we miss things, Scheduled dates are often definitive dates, leaving no room to represent the amount of uncertainty we have for that feature, should be focusing on range to express the uncertainty of our estimate

Estimates Become Commitments, Estimates are a probability, probability of something from 0%-100%, Commitment is not a probability, commitment is a date, We can't equate a date to the probability of something happening, Only date we can trust is the 100% but 100% may be an absurd date like 10 years away is 100%, Need to evaluate a variety of business factors and risks to give estimates, These are just estimates though, not commitment

An Agile Approach

An Agile Approach to Projects, Work as one team, No "throwing over the wall" to each other mentality, Product owner - gives the vision and makes decision that lead to a good return on investment, Customer - funding the project, or buying the software, Developer - programmers, testers, analysts, db engineers, usability experts, technical writers, architects, designers and so on, Project Manager - focus on leadership vs management, Work in short iterations, timeboxed - often 2 or 4 weeks, Deliver something each iteration, Product brought to a potentially shippable state at the end of each iteration, Does not require release every iteration, just potential release, Focus on business priorities, deliver feature sin the order specified by the product owner, focus on completing and delivering user-valued features rather than on completing isolated tasks, Uses user stories and conversation to understand and act on the real value intended for the users., instead of long winded written requirements with lots of assumptions and no one to understand the background to answer the right questions, Inspect and adapt, incorporates all new knowledge gained in the preceding iteration and adapts accordingly, Plan is changed and value of the plan has increased

An Agile Approach to Planning, Not solely an execution of a series of steps, A rapidly and reliable generation of a flow of useful new capabilities and new knowledge, knowledge that is used to make the product the best that it can be, product knowledge, helps us know more about what the product should be, project knowledge is information about the team, the technologies in use, the risks and so on, Traditional project is like running a 10k, you know how far you have to go and you try to get there as fast as possible, Agile project is more like a timed race, you know when you will finish but not what they will deliver, Knowing this allows us to plan to to revise goals that lead to a longer-term objective, Multiple Levels of Planning, Imagine planning a twenty-mile trip but can only see over four miles, plan on looking ahead and re-planning at least 5 times, Three distinct horizons, Strategy - Portfolio - Product, release, theme focused for a release, occurs throughout the project, often at the start of each sprint, iteration, Story/task level planning, start of each sprint, current day, coordinate work and synchronize daily efforts, daily scrum - 15min timebox, Conditions of Satisfaction, Objectives for the project, example: best word processor of the world, and schedule, budget and quality, Sprint planning the team finds the conditions of satisfaction from the Product Owner about each story, scope, schedule, budget and quality, All conditions sometimes cannot always be met, can build the best word processor, but not by next monnth, Must allow for the conditions to change

Estimating Size

Estimating Size with Story Points

Story Points Are Relative, unit of measure for expressing the overall size of a user story, raw value of points are unimporant, what matters are the relative values, a two should be twice as much as a story that is assigned a one

Velocity, measure of team's rate of progress, summing number of story points that the team completed during the iteration, Estimate size and derive duration, estimate size of backlog and derive how long to complete via dividing by the velocity = # of iterations, Corrects Estimation Errors, planning errors are self-correcting, velocity changes throughout the project and thus the duration of the project changes so the plan is more accurate and more valuable, imagine estimating painting rooms of a house based on floor plan, estimate sizes of room with points, you don't know how long to paint any room, but you know some are twice as long as others, after a few rooms you will have a better estimate on how long to finish the house, Estimating effort, not duration

Estimating in Ideal Days

Defined, amount of time that something takes when stripped of all peripheral activities, football games is 4 15min quarters - 60m ideal time

Elapsed time, defined, amount of time that passes on a clock, football games elapsed time is 3 hours

Ideal Time & Software Development, Elapsed times comes from lots of things, supporting current release, sick time, meetings, demonstrations, personnel issues, Phone calls, special projects, training, email, reviews and walk-throughs, interviewing candidates, task switching, bug fixing in current releases, management reviews, Assumptions to estimate in ideal days, only thing you will work on, everything you need will be on hand when you start, there will be no interruptions, assign one aggregate estimate to each user story, don't have, x ideal days for this person, y ideal days for this person

Techniques for Estimating

Be aware of diminished return on investment when estimating, accuracy goes up, then back down after too much effort in estimating

Estimates are Shared, Estimates are best derived collaboratively, We don't know who will work on a task, Outside view is valuable, well known similar tasks took person X less time, X is just too close to the problem / down in the weeds, The Estimation Scale, best at estimating things that fall within one order of magnitude, 1, 2, 3, 5, 8..., or, 1, 2, 4, 8..., Allow 0, can be used for the rare trivial task to not count against velocity, entire team has to understand 13 x 0 != 0, User Stories, Epics, and Themes, Stories could be paper clipped together to form epics as stories are created, goal is not stories all within one magnitude because it could lead to too much detail on features that may never get worked or may be a long time before being worked, Deriving an Estimate, Expert Opinion, expert relies on intuition or gut feeling, less useful on agile then on traditional, more than just one expert will be working the feature, usually a quick estimate, good amount of evidence showing this can be more accurate then thorough, analytical approach to estimating, Analogy, This story is a little bigger than that story, lot of evidence that shows we are good at estimating relative size than absolute size, Compare a new story to an assortment of those that have already been estimated, To triangulate, compare the story against a couple of other stories, Disaggregation, Splitting a story into smaller, easier-to-estimate peices, Huge stories are harder to estimate, Planning Poker, Best approach according to Cohn, Combines all of the deriving techniques above, How to play, every team member gets a deck of cards, 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100, moderator reads the description of a story, Product owner answers any questions that the estimators have, keep in mind the effort/accuracy curve during this phase, Each estimator privately selects a card representing their estimate, cards are not shown until all estimators have made a selection, All cards are shown sumltaneously, If differing numbers appear, high and low estimators explain their esimates, goal is to learn what they were thinking, not an attack, Few more minutes of discussion, notes are taken on the story so that discussion is not wasted, Re-estimate occurs by cards again, Convergence or repeat, does not require everyone to throw the same card, if off by 1 or 2, ask if it's okay for convergence, does not require everyone to throw the same card, if off by 1 or 2, ask if it's okay for convergence, Again, point is not absolute precision, but reasonableness, Right Amount of Discussion, to help not go too far right on the effort/accuracy curve, buy a 2 min sand timer, anyone can flip it over at any time, no scheduled use, after the timer, everyone picks/shows cards, discussion can continue again, but someone can immediately flip the timer also, Smaller Sessions, it is possible to planning poker with a subset of the team, not ideal, At least 3 people to do this, Good idea to focus on analogy estimating for this to work well, When to play, A few sessions a the start of a project to kickstart stories and estimates, plan to hold a very short estimation meeting near the end of each iteration, This keeps up on new stories as they are added and prioritized, Why Planning Poker Works, Brings together multiple expert opinions, Lively dialogue ensues during planning poker, estimators are called by their peers to justify their estimates, improves accuracy of estimates, especially on items with large amounts of uncertainty, result in estimates that better compensate for missing information, Averaging individual estimates leads to better results, It's fun

Re-Estimating

Should only re-estimate only when we believe a story's relative size has changed

When Not to Re-Estimate, Estimated 4 stories at 3 thinking they could get 12 points done, only got 6 done, team says, they were all twice as big... so they want to resestimate the next 2 at 6 points, don't, Velocity Is the Great Equalizer, As long as stories are consistent and relative, velocity will average out correctly, that's its purpose, Velocity is an ever changing number, it will compensate for in-precise release planning estimates and update the planning estimates to be more accurate with each iteration, Re-Estimating in hindsight mixes estimates with work done, and looking forward we don't know which stories will also need to be re-estimated in hindsight or are actually correct

When To Re-Estimate, Example, Team works a story with an aspect of charting, Charting took a lot longer than they thought, many stories had a charting aspect which was assumed to be trivial-1 pt, They should NOT re-estimate just the original, or do no re-estimating, They should re-estimate all stories with a charting aspect to update the relative size of those stories with a now known quantity, this is to include the one in the previous sprint which realized the mistake, so that velocity can be more accurate

Re-Estimating Partially Completed Stories, Velocity generally should be an all or nothing mentality, it will be lower one sprint, but then be higher the next, velocity is the great equalizer, If the unfinished portion of a story will not be done in the next sprint, Split the story into 2 and re-estimate both, estimates of the 2 do NOT need to be equal to the original estimate, Or, don't have partially complete stories, finish them all

Choosing between Story Points and Ideal Days

Considerations Favoring Story Points, Story points help drive cross-functional behavior, help teams learn to work cross-functionally, needs to be a single number that represents all of the work for the whole team, Story point estimates do not decay, Ideal days can change based on the team's experience with the technology, domain and eachother, among other factors, Story points are a pure measure of size, Means we can only point stories by analogy, Ideal days continue to think about time to completion and not analogy, Estimating in story points typically is faster, Ideal days means we want to understand more than relative estimates so that the time commitment is more accurate, Story points are more known to be relative estimates, thus the extra time estimating is not needed, My ideal days are not your ideal days, Team members of different experience and expertise at the same point in time can not compare the same amount of previous work because they probably did that work at different stages of their experience and expertise

Considerations Favoring Ideal Days, Ideal days are easier to explain outside the team, intuitive, amount of time, very similar to traditional estimating while adding the 'ideal' part to remove some assumptions, Ideal days are easier to estimate at first, Estimating initial story points can be difficult, no baseline makes it unsettling, initial story pointing often is over very very quickly

Recommendation, Story points

Planning for Value

Prioritizing Themes

Factors in Prioritization, Financial Value, How much money will the organization make or save, Estimate financial impact over a period of time - few months, quarters or possibly years, Can be difficult to estimate, estimating number of new sales, average value of a sale, timing of sales increases etc, Often useful to have an alternate method fo estimating value, "desirability", (covered later), Cost of Development and Support, Cost can change over time, may take 4 weeks now, and 6 weeks later, doing 4 weeks now, may lead to changed requirements with more knowledge gained, thus spending 4 more weeks later changing the initial functionality, Best way to to reduce cost of chance is to implement a feature as late as possible, when there is no more time for change, Themes often seem worthwhile when viewed only in terms of the time they will take, (as opposed to cost), Do it in story points/ideal days, derive cost from there, (covered later), Amount and Significance of Learning and New Knowledge Created by Developing the Features, Types of Knowledge, Knowledge about the product, Knowledge about the project, Reduces uncertainty, Early on these will be a large factor, return on this investment is very high, Later on these will have diminished return on investment and be less of a factor, Amount of Risk Removed by Developing the Features, Types of Risk, Schedule Risk, "We might not be done by October", Cost Risk, "We might not be able to buy hardware for the right price", Functionality Risk, "We might not be able to get that to work", Suggested prioritization is to consider both risk and value, for quadrants of the risk-value relationship, combining risk and value in prioritizing features

Combining the Four Factors, Examples, Infrastructure, Say Security, Limited to no value alone without other functionality we are securing thus not usually values to prioritize first, Upfront cost will be less than later, Security will unlikely lead to knowledge about the product, but it may about the project, Risk to the project's success that could be reduced or eliminated by implementing security earlier rather than later?, probably not, User Interface Design, Will the UI generate significant useful new knowledge?, primary user interfaces will be yes, smaller features later will be no, Will it reduce risk?, Doesn't eliminate technical risk, May help tremendously reduce risk of developing the wrong product, Will cost be lower if done up front?, Usually not

Financial Prioritization

Cohn Likes, to hold a meeting attended by as many of the individuals capable of forecasting financial value as possible, to perform theme valuation meeting - and complete the form, Also will need to look at, net present value, internal rate of return, payback period, discounted payback period, Individuals will probably include, product owner, the team, sales team, marketing team

Sources of Return, New Revenue, New Customers, Incremental Revenue, Incremental revenue from existing customers, Can Result From New System/Product, Encourages existing customers to purchase more licenses, Includes optional, add-on modules that can be sold separately, Includes features that allow charging a higher price, Encourages the user of consulting services (for example, to integrate with a separate third-party application), Retained Revenue, the revenue an organization will lose if the project or theme is not developed, Customers expect new features to continue supporting their growing/changing business, customers may use other products if key features are missing, These can also lead to incremental revenue, Operational Efficiencies, Most often related to your own inefficiencies, Develop tools to do our job more efficiently thus saving money long term, example, returns are low and slow, automating returns may be a big operational efficiency if returns increase, Likely Places Include, anything that takes a long time or would take a long time if the company grew, Better integration or communication between departments, reduced employee turnover, Shorter training time for new employees, Any time-sensitive process, Combining multiple processes, Anything that improves accuracy and reduces rework, An Example: WebPayroll, <notes excluded>, example of development costs, example of all costs

Financial Measures, Time Value of Money, to buy a $5 burger next Tuesday might need to put $4.99 in the bank today, present value, amount needed to invest today to have a known amount in the future, discounting, process of moving future amounts back into their present value, opportunity cost, rate at which organizations dicsount future money, Net Present Value (NPV), formula for evaluating a theme, NPV for WebPayroll example, easy to calculate and easy to understand, doesn't capture cash flow streams, 2 projects, one with low up front investment, one with high, each with same NPV, Internal Rate of Return (IRR), aka Return on Investment (ROI), a measure of how quickly the money invested in a project will increase in value, can more readily compare projects, Cash Flows comparisons, interest rate at which the NPV of a cash flow stream is equal to 0, formula, Many organizations will specify a minimum attractive rate of return (MARR), they like to invest less for better IRR over NPV, free money to invest in other things as they come up vs having money tied up, Can't be used alone, sometimes IRR % is high, but may be overall low net gain, and may tie up key resources from other work, Payback Period, definition, amount of time required to earn back the initial investment, 7 quarters payback period example, calculations and interpretations are straight forward, measures the amount and duration of financial risk, fails to take into account the time value of money, Discounted Payback Period, apply the appropriate discount factor to each item in cash flow stream of payback period, example, Comparing Returns, Never cut and dry, compare all types, compare which help other themes, overlap, which work well together etc, Next Reference, Steve Tockey's Return on Software: Maximizing the Return on Your Software Investment (2004)

Prioritizing Desirability

Kano Model of Customer Satisfaction, Threshold, or must-have, features, improving the performance or amount will have little impact on customer satisfaction, (bed, bathroom, desk of hotel), Linear features, "the more, the better", (wifi, size of room, number of machines in fitness center of hotel), Exciters and delighters, provide great satisfaction, often adding a price premium to a product, lack of these will not cause dissatisfaction, Customer satisfaction of each, chart, threshold features, should be present before initial release, partial implementation may be adequate, linear features, should be placed on completing as many linear features as possible, only exception is project with too many features, delighters, with time permitting few delighters should be prioritized such that they are included in the release plan, Assessing Themes, Customer Surveys, can be done by surveying customers, may need less than 20 to thirty to accurately prioritize requirements, determine category by asking 2 questions, how the user would feel if the feature were present, functional form, how the user would feel if it were absent, dysfunctional form, 5 point scale, 1. I like it that way, 2. I expect it to be that way, 3. I am neutral, 4. I can live with it that way, 5. I dislike it that way, Categorizing Responses, interpreting results, adding together the answers, Relative Weighting, Relies on expert judgement, collaboratively, but led by the product owner, scale of 1-9 on benefit and penalty, chart

Splitting User Stories

current page

121