How do you estimate the entire project timeline using SCRUM framework

[manas ghosal]

Hello All,

       We are presenting to the management, the fact that our team desperately needs SCRUM framework in place, as an improvement to what ever it is now. Out of the many questions, about SCRUM that I could more or less answer with many hiccups, one question that I couldn't find an answer is that

"How do you estimate the entire project timeline using SCRUM framework? How do we show the project timeline to the management (Burndown chart, etc) ?"

      Does anyone have any suggestion or mind blowing answer?

Thanks,

Manas

[Rick Lim]

Hi Manas,

I do not know how others have done it, but for my case, the initial estimate is done similar with traditional water-fall from a requirement workshop. Once we have the high level estimate in T-shirt size, we roughly estimate the number of man-days per each size. Then added some buffer (in my case here we added 30%) to come up with the initial budget. However, the management still making business decision on the investment at each release. In my case here we have a fixed release quarterly. In this case, the management could decide to stop further investment, continue or increase, with the information of revised estimate and changes to the product backlog. We have just ended one release and in the midst of developing the second, but I am sure management would be able to make better decision when they have ROI result from our first release.

Hope this help.

Cheers!

Rick

[Pete Deemer]

hi!

for a quick overview of agile estimation and planning, see http://www.mountaingoatsoftware.com/uploads/presentations/Agile-Estimating-Planning-Agile-Development-Practices-2008.pdf

for more in-depth, check out http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn-ebook/dp/B004X1D3TC/ref=tmm_kin_title_0

Best regards,

Pete

[Manoj Vadakkan]

Hello Manas, 

I wish you the best in this presentation to the management. 

I do not have a mind blowing answer  for your question :-) Scrum framework is silent on how to estimate timeline for a project. 

What process are you following today to estimate projects at your organization? How is that working? Is it taking too long to estimate a project? If so, there is value in changing that - to find a low cost, faster approach to estimate. 

Here is one approach that might work for estimating.  

1) A project comes in to the input queue 

2) Get a few key people ( chief engineer for the group, business person,). They analyze the project (couple of hours to couple of days). 

3) With enough information, they compare that effort to something that they have done in the past. Based on these, they come with a number, even better a range. 

This range is then used to decide if this project is worth undertaking and other things such as to estimate how many people we need for how long or how many other projects we can do at the same time, etc, etc. For any of those reasons, a range, a high level estimate that you can come up with quickly is good enough, in my experience. If you are not convinced, think about how long did you spend estimating your large project last time? How much did you end up really spending compared to what you estimated? 

Once the organization decide to undertake that effort and as you make progress, you may use the story points and burn-up/down chart, as you suggested in your question. 

Your management is convinced? They want a better & precise estimate? I sometime pulled out the “cone of uncertainty” from my back pocket to try to convince that, we (software people)  are not good at estimating work in the beginning of a project.  (google the term “cone of uncertainty” and you will find details).  

Does any of that help? 

Manoj Vadakkan
==============================
309-750-3553 (c) ma...@vadakkan.org

Upcoming CSM classes at : Denver, Chicago, Kansas City, Salt Lake City, Frankfurt, Amsterdam

Conference: Project Zone Congress @ Frankfurt, Lean+Agile @ DC

=========================================================================

--
You received this message because you are subscribed to the Google Groups "Agile Singapore" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agilesingapor...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Benjamin Scherrey]

    There's a bit of an impedance mismatch between the typical following a plan-based approach for software development versus a discover-based approach which Agile processes, such as SCRUM call for. Software development is one of the most complex undertakings known to man. If your project isn't doing something quite new and valuable (therefore complex) then it probably isn't worth doing. This also means if your project is going to deliver significant value it is, by definition, impossible to know everything up front well enough to create a prescribed plan detailing every feature and the effort required to complete it in a reasonable amount of time & effort (reasonable being significantly less than the effort of actually doing the thing you're trying to predict). In order words - Agile processes finally abandon the absurd notion that all predictive processes suffer from which is the presumption that we know things that cannot possibly be known. That's why managers have no scruples when they play "manager math" with their team's estimates cause they know it's all fiction to begin with. All such projects are launched based on complete fabrications and hubris. This is the current state of software development plans at your company no doubt.

<rant>

    "But wait!" argues management  - "we need to know how much something is going to cost before they can give approval, right?" While true that's actually only half correct. To know whether or not a project should be approved you really need to have a good idea of it's return on investment. And to compute an ROI, business needs to come up with what the expected return would be if the goals of the project are met. Only when the connection between project goal and business value return is explicitly spelled out can a team even begin to know how to drive the technical direction of the project that determines it's cost. Sadly the management teams most insistent on knowing every detail of the cost and time of their project are the ones most incapable of defining it's value in any meaningful manner - and THIS is why 80% software projects end up as failures because there's no objective determination of goal/value to drive solution/costs. It's almost never a technical issue.

    Anyway - good luck winning your case if you insist on pointing this inconvenient truth out to your superiors unless you are more diplomatic than I. But you need to know this fact when you seek to identify the appropriate solution for your project request. Frankly insisting on this being part of the process would guarantee 90% of enterprise projects never get started and put most vertical scaling solutions like Oracle/SAP/Dynamix/SANS out of business in a year.

</rant>

    So now you've tried to get some idea of the business value of your project (frankly it's usually someone's political fight rather than a legitimate motive but we strive to find where actual business value happens to overlap in the Venn diagram. Once you have some footing on how goals -> business value map you are ready to begin estimating your project. I do the following:

1. Create high-level use cases for the primary system interactions. These are text narrative style (never ever diagrams and never ever UML) use cases as described in http://www.wirfs-brock.com/PDFs/Art_of_Writing_Use_Cases.pdf . Your goal is to identify primary stake holders, system components/services, domain objects (which are hosted on the services), and the interactions between said objects. Notate each use case with it's non-functional requirements like capacity, performance, and resiliency.

2. Now if I'm being paid to build a project plan (rather than just deliver a quick quote for a client) I will do formal risk/benefit analysis. The best book describing how to do this is the short but wonderful "Wa;tzing With Bears" by Tom DeMarco http://www.amazon.com/Waltzing-With-Bears-Managing-Software/dp/0932633609 . For each use case you can go through and identify risks and values. This will objectively determine what your risk mitigation strategy should be for each issue and the amount of budget you should allocate for that purpose. The great thing about this is, as risk items are passed, you will be able to more accurately track the status of the project deadline and budget with great confidence. This is something that is a consulting effort that is very much worth the price. Feel free to hire me if you can get budget for it. My rate is USD $1500/day typically for 1-2 weeks and if your project will take > 90 days to complete it's a bargain. :-) Seriously.

3. Now you start estimating. Create a spreadsheet that breaks down each component by it's domain objects, main interactions (the sub-use cases between these objects that make up the bigger use cases), and don't forget to add sections for the non-functional requirements for each component. Each line item should be small enough that the team responsible can come to quick consensus regarding the combined design+develop+test+deploy effort. 

Here's where Agile concepts first show up in the process. Go get Mike Cohan's "Agile Estimating and Planning"   http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415 (best book for any Agile/SCRUM team to start off with) and read the sections on Ideal Days, Story Points, and Planning Poker. At this level we're dealing with Epics and not individual User Stories. In this case only, one may argue for using Ideal Days instead of Story Points. They'd be wrong but it can be argued. :-) When you start your first release or iteration planning meeting and start breaking out User Stories DEFINITELY switch to Story Points and don't try to map back to your Epic estimates - just start a new scale. I kinda use a balance between Ideal Hours and Story Points which I tend to call Epic Points. This is useful for new projects and new teams that haven't already established a Story Point range for comparison. 

Start off estimating a few items that the team believes are your most common sized efforts given the breakout from your Use Cases. Assign those 2, 3, or 5 Epic Points taking note of their relative complexity and paying attention to make sure the scale makes sense when you want to make your smallest estimate of 1 Epic Point for other items. Shift your scale left or right until it kinda fits. 

Next go back and sample some of the 2 and 3 point items that your team has the best understanding of. Have the combined team (remember SCRUM - everybody all together from the beginning - cross functional team) determine the number of hours required to complete this item from design, develop, test all the way to deployment. If a 2 point item is 10 hours then you should be able to confirm a 1 point item being 5 hours and a 3 point item being 15 hours. Test your estimates against a number of items for comparison and revise their Epic Point assignment and Ideal Hours/Epic Point until their relative values line up. 

4. Now you've got the ability to size the EXPECTED effort. But we know that we can't actually know all this so now we need to show what our uncertainties are in no uncertain terms. Your spreadsheet should have 3 Epic Point entries for each item - Min Points, Expected Points, Max Points. Your estimates til now have been "this is what the effort is if our assumptions & expectations hold true". You also need to add "best case" and "worst case" estimates. Here's where you can apply the results from Step 2 to your cost estimates in terms of Epic Point impact. If you haven't done the formal risk analysis then your team needs to try to come to consensus about what the best and worse case scenarios would be. Ultimately, the farther apart these numbers are the more risk or uncertainty is present. A more narrow range demonstrates that your team is more confident in those estimates.

5. If you've done formal risk analysis from Step 2 you can now run a monte-carlo simulation of your risk occurrences and provide an Epic point estimate range of numbers that can be well supported by the team. You now have a good handle on the SIZE of your project. So what's it gonna take to do it?

6. Since you've assigned a number of Ideal Hours to each Epic Point, you should now estimate how many Ideal Hours each team member can apply towards the project per iteration. Total these hours then divide by the Ideal Hour/Epic Point ratio to determine your team's estimated project Velocity. That is the number of Epic Points the team should be able to complete each iteration. Divide the Min, Expected, and Max Epic Point totals by your expected Velocity and you've got an estimate of the number of iterations the project can be expected to take for this team. Done!

REMEMBER when you launch the project and start off planning your initial release and iteration do NOT attempt to match your Story Point scale to Epic Points. Create an entire new scale for your Story Points and switch to a discover based approach for determining velocity from that point forward.

The reality is after your first few iterations the priorities and understanding of the project will change considerably. Here's where the Burn Down Chart helps keep things on track and gives management a powerful tool to change their scope and immediately see the impact on their schedule/budget by allowing them to remove or add scope each iteration. This is a capability they would not have using their strictly predictive approach to project planning. Before your features were fixed and time and cost became variables. Now your time and cost can be fixed and features become variable but since you're always working on the highest value features first (you know this because you identified your solution -> goal/value impact earlier, right?) you are getting a higher ROI for your development effort than you would have otherwise been able to. That's the mind blowing part for management once they experience being able to pivot without costly change request processes. :-)

   Hope this helps. I think I need to turn this into a blog post. Let me know if you have any questions or comments.

  -- Ben

[manas ghosal]

Thanks to all of you for taking time to answer my question. Since the past week and throughout the weekend and still on, I am trying to digest your points and browsing through the web materials.

What I understand is to do the estimation as what we do in a typical water fall, but do it more systematically taking into account the risk factors. Most probably use the 3 epic points. We will try to figure something out. I will definitely have more questions.

Thanks again.

Manas.