{"id":53928,"date":"2021-09-06T10:48:24","date_gmt":"2021-09-06T05:18:24","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=53928"},"modified":"2024-07-01T12:15:34","modified_gmt":"2024-07-01T06:45:34","slug":"agile-project-management-estimating-the-unknown","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/agile-project-management-estimating-the-unknown\/","title":{"rendered":"Agile Project Management: Estimating the Unknown"},"content":{"rendered":"

Estimation<\/b><\/h4>\n

Experienced project managers know the first question clients ask on any new project is \u201cHow much?\u201d followed closely by \u201cHow soon?\u201d Whenever the subject of agile project management is discussed, it\u2019s inevitable that one question will be asked: \u201cHow do you provide the client or sponsors with an estimate when you have no complete requirements document, no signed-off specification, and no ratified schedule?\u201d Opponents of agile methods, deeply committed to the structured and predictive techniques championed by the\u00a0Project Management Institute<\/u><\/a>\u00a0(PMI) and the\u00a0Software Engineering Institute<\/u><\/a>\u00a0(SEI) at Carnegie Mellon University, point to this difficulty as the nail in the coffin of agile methodologies. Even organizations that are eager to try agile methods often raise this question with trepidation. Whenever I write a column about agile methods, this\u00a0question of estimation<\/u><\/a>\u00a0pops up in the comments without fail.<\/span><\/p>\n

Estimation in Agile<\/b><\/h4>\n

Before we explore estimation techniques in an agile environment, let\u2019s remember a fundamental fact: Even in highly predictive, mature project environments like those recommended by PMI and SEI, estimating is a serious challenge, and estimates developed (even with thorough requirements and multiple user signoffs) are frequently wrong. I note this so we don\u2019t begin our discussion of agile estimating under a misapprehension.<\/span><\/p>\n

The questions often asked about agile estimating are just as valid when asked about predictive methods. We may have gathered and documented binders full of user requirements and gotten sponsors and stakeholders to sign them in blood, but users will still reserve the right to say \u201cNo, that\u2019s not it\u201d when we show them our first prototype. The fact that we\u2019ve got a 300-step project plan with activities scheduled to the hour doesn\u2019t mean that the work will occur as predicted. In short, when we challenge agile proponents to prove that iterative, incremental development methods can be estimated, we shouldn\u2019t be surprised if they turn right around and demand to see the spotlessly accurate estimates we\u2019ve created in our predictive projects.<\/span><\/p>\n

This is not to deny that there are benefits to crafting a complete specification and project plan up front and using that as a basis for estimating. Especially in projects that are similar to ones we\u2019ve delivered previously, history can be a meaningful guide and can enable us to derive relatively accurate estimates based on tasks we\u2019ve done before. As noted in my previous column,\u00a0agile methods are most appropriate in innovative projects<\/u><\/a>, which lack this historical record. It\u2019s in these inventive projects (without analogies of previous efforts to lean on) that the real challenge of estimation in agile programs emerges. Estimation is a challenge in any project effort, but in these never-before-seen initiatives, it can seem impossible.<\/span><\/p>\n

IIn fact, it\u2019s not. Some simple concepts can make agile estimating much less intimidating than it seems. The first general principle, which is valid in both agile and predictive project environments, is \u201cdon\u2019t estimate further than you can see.\u201d When we apply an incremental development approach, projects are divided into a series of iterations; each iteration results in the delivery of a working prototype that the client can evaluate and then be modified or expanded. Most agile techniques call for each iteration to be both time bound and feature bound. Ahead of the development of each iterative prototype, the team and sponsor agree on how much time they\u2019ll take to deliver that iteration and which features will be delivered. Under that method, it becomes pretty obvious how to estimate the time required to deliver that iteration; it\u2019s the \u201ctime-box\u201d (to use the common agile language) that\u2019s been established by mutual consent. That time-box is usually established by listing the features expected to be delivered in the iteration at hand and estimating how long it will take to deliver those features.<\/span><\/p>\n

\"\"<\/p>\n

Estimating the Unknown<\/b><\/h4>\n

As an agile project begins, the set of features to be delivered initially is often confined to the most fundamental features required to validate the project concept, with the \u201cbells and whistles\u201d and the more advanced capabilities deferred until later iterations. So, from the long list of features documented as elements of the ultimate product, we select those features for the initial iterations that will demonstrate that the underlying concept is feasible, and that will allow the client to begin the \u201cmore of this, less of that\u201d conversation that inevitably occurs when we expose the prototype to the sponsor community. By limiting the early iterations to this reduced feature set, we make it easier to agree on a time-box for those features. We\u2019re only estimating the iteration at hand, with the estimation of future iterations deferred until we\u2019ve got a clearer idea of how closely our developed prototype matches the customer\u2019s vision and expectations. Then we repeat this process, iteration by iteration.<\/span><\/p>\n

\"\"<\/p>\n

This doesn\u2019t answer the dilemma of budgeting for the entire project, which is often what sponsors expect. After all, the purpose of an estimate in the corporate world is to enable the sponsor to set aside a budget for the entire initiative, not just the current iteration. This estimating task is also not that baffling, either. As iterations are time-bound, entire projects are both time-bound and cost-bound. When a homebuyer asks a construction company to build a house, the obvious first question is, \u201cHow much are you willing to spend?\u201d The next question is usually, \u201cWhen do you expect to move in?\u201d after which the development of plans and features can begin. The client sets the budget that regulates the features that will be included in the new home, from the most humble pre-fabricated trailer to the most luxurious mansion.<\/span><\/p>\n

This analogy also applies in the agile world. Rather than specifying every feature that the sponsor dreams of and then (often imperfectly) estimating the entire cost from ground-breaking to move-in, the agile developer, like the home developer, starts with the sponsor\u2019s available budget and then determines what can be delivered within that budget, and the time-box that the budget implies. In agile projects, as in projects delivered in a predictive methodology, the developers must set reasonable expectations for the sponsor so they\u2019re not expecting the Taj Mahal on a bungalow budget, the question in agile development is not \u201chow much will it cost for all these features?\u201d but instead \u201chow many of these features can you include within this budget and time-box?\u201d<\/span><\/p>\n

Estimating IT development projects will always be a fraught activity; since the technology is complex, users frequently change their minds, and things often don\u2019t work out as planned. This is true whether the approach is agile or predictive. In agile engagements, we estimate incrementally just as we develop incrementally, and we do all this development and estimation within the bounds of an agreed budget and time-box that\u2019s established in collaboration with the client at the beginning of the effort.<\/span><\/p>\n

<\/div>","protected":false},"excerpt":{"rendered":"

Estimation Experienced project managers know the first question clients ask on any new project is \u201cHow much?\u201d followed closely by \u201cHow soon?\u201d Whenever the subject of agile project management is discussed, it\u2019s inevitable that one question will be asked: \u201cHow do you provide the client or sponsors with an estimate when you have no complete […]<\/p>\n","protected":false},"author":1395,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":56},"categories":[5878],"tags":[324,4922,936],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/53928"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1395"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=53928"}],"version-history":[{"count":4,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/53928\/revisions"}],"predecessor-version":[{"id":54440,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/53928\/revisions\/54440"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=53928"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=53928"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=53928"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}