Project Management

Please login or join to subscribe to this thread

Schedule Estimate

linkedin twitter facebook   Agile   Estimating   Information Technology   PMO   Work Breakdown Structures (WBS)  
avatar
Khushboo Singh Project Manager| Envestnet|Yodlee Bangalore, Karnataka, India
How do we estimate an Agile project?
Should we simply go ahead and work with Architects, Solution Designers, Developers and Testers and find out how much effort is needed from their side; add project management effort and buffer?
Practically, do we use a different methodology for Agile Schedule Estimation?
Sort By:
< 1 2 >
avatar
Adrian Carlogea Australia
Stéphane, some customers just want to know from the beginning how much the whole project is going to cost them and how long is it going to take. While it is probably impossible to give them an accurate answer since most of the times they don't even know what exactly they want you still need to provide some values to them.

In order to achieve the above no matter what method you are going to use you need technical experts to review the requirements figure out what needs to be done and give some effort estimates.

Khushboo, said that they are not going to involve technical experts in the estimation process which in my opinion is simply insane. :) On all the projects that I have worked technical experts were involved from the beginning form pre-sales. You can't go to a customer and promise things if you don't know if what you promised is achievable.
avatar
Khushboo Singh Project Manager| Envestnet|Yodlee Bangalore, Karnataka, India
When you say Technical experts, do you mean Developers or Designers or Architects or all?
The organizations I have worked with, have a separate Functional Team and we can get Business Analysts and SDs; but getting Developers would be difficult as in the initial phase w e would not have a team formed for the project; until the project is finalized.
...
1 reply by Adrian Carlogea
Oct 20, 2016 12:26 PM
Adrian Carlogea
...
By technical experts I mean the people that have the required skills to perform the work needed on the project.

It does not matter what project management methodology you are about to use, technical experts must be involved even before the project starts to assist the sales team.

Making promises to customers without knowing the opinion of the people that are going to perform the work is very dangerous and I have never seen something like this in any of the projects on which I have worked. Yes sometimes the technical experts involved in the early stages may not end up working on the project but other experts from their line of work will.

If no technical expert is involved in the estimation and planning there is a high risk that the team members that would start working on the project to realize that the plan is not realistic and it would be impossible to deliver in time.
Khushboo,
I answered several bids where the clients required an Agile approach with a Certified Project Manager and a Fixed Price. Probably is similar with the one you have in hands. From my experience,what the client really wanted was a Fixed price, a certified project manager and a methodology to deliver product iteratively. I don't know the terms of you RFT but you have two possible approaches.
1. The client already know what he wants and he included all the requirements in the RFT.
2. The cliente only knows the high level of the application and require an Agile approach with discovery along the project.

For situation 1, I would offer other software engineering methodology. Seat with experts and create a very good detail about what you are offering and about your assumptions. Add some UML and Mockups. Show the client that you completely understood all the requirements and that you are able to meet their requirements. Have some experts together to estimate the effort. Include some history about your past project to give more "security" to the potential client and to guarantee that you can do that kind of job.

For situation 2, since you don't know the requirements is impossible to give a fixed price. For this situation make a proposal with your understanding and offer a real Agile approach with a T&M contract. You can include the price hour for developer, design, PM, etc. This approach is more related with the budget the client have available.

Hope that helps.
avatar
Adrian Carlogea Australia
Oct 20, 2016 1:07 AM
Replying to Khushboo Singh
...
When you say Technical experts, do you mean Developers or Designers or Architects or all?
The organizations I have worked with, have a separate Functional Team and we can get Business Analysts and SDs; but getting Developers would be difficult as in the initial phase w e would not have a team formed for the project; until the project is finalized.
By technical experts I mean the people that have the required skills to perform the work needed on the project.

It does not matter what project management methodology you are about to use, technical experts must be involved even before the project starts to assist the sales team.

Making promises to customers without knowing the opinion of the people that are going to perform the work is very dangerous and I have never seen something like this in any of the projects on which I have worked. Yes sometimes the technical experts involved in the early stages may not end up working on the project but other experts from their line of work will.

If no technical expert is involved in the estimation and planning there is a high risk that the team members that would start working on the project to realize that the plan is not realistic and it would be impossible to deliver in time.
avatar
Heidi chan Sydney, Nsw, Australia
I use a solution architect and/or tech lead to help with early estimation. First you need to know your epics (scope). We then estimate using t- shirt sizing (which also gives us points). We then add a contingency factor to each epic if required (multiplier). We then determine squad members and estimate squad velocity (based on history). After then it's just maths. I'm ignoring infrastructure but you should take this into account.
avatar
Mario Marzuki Project Manager| SKY Network Television NZ Auckland, New Zealand
Hi Khushboo

What an interesting question you have presented and it is also a classical problem. We are familiar with forecasting how long a product will take to deliver once the Remaining Size and Development Velocity are both known - and this can only be so after work has started. But how on earth are we supposed know how both of these when we haven't even recruited the delivery team?

In an IDEAL world (I say that because we don't always live in an one), you can usually use a Top-Bottom estimation (rather than the typical Bottom-Up /WBS) by making comparative estimate for this product against ANOTHER agile project/product that the company has previously delivered.

Often you may not be able to make a direct comparison between one Product to another because every Product is usually very different and complex (If they were all the same and repeatable then you wouldn't be considering Agile delivery to begin with!!). Therefore we usually find it easier if you break down the Product at very least into its constituent Epics (large deliverable chunks) and draw comparative estimates between these epics and other epics of known size.

You can even derive the velocity forecasting in similar fashion.
For example -
"We know from past experience that Product A backlog contained a total of 1500 story points. We needed 6 months to release our first usable version, with a team of 5 people."

"We are roughly estimating that the new Product B is roughly double the size at 2500-3000 story points. Assuming we are going to have similar team and velocity then we would probably need 10-12 months."

The LAST thing you'd want to do is to apply Bottom-up estimation where you break everything down into constituent tasks and then estimate them in hours / overlaid with resourcing capacity.
First reason for NOT doing that is because you don't have the team in hand yet which means those estimates are probably not going to be reliable anyway.
Secondly by preferring Agile delivery this tells me that the product you're about to build is complex and subject to much uncertainty. This means the WBS-based estimate which you work so hard to provide will almost certainly become inaccurate as soon as work starts.

Also I am making the assumption here that your project customer is internal to the organisation - if you are trying to deliver to an external customer under a contract then this explanation needs to be waaaaaaaaaaaaay expanded.

Feel free to PM me directly if you wish to discuss further!

(I'm a PMP and PMI-ACP)
avatar
Mario Marzuki Project Manager| SKY Network Television NZ Auckland, New Zealand
I forgot to add that when doing Comparative estimates between products/epics at high level - you only need Architects/Designers/Analysts- type people in the room.

Ideally these people have also been across the other products/epics that you are trying to compare against.

Their estimates need to converge. You need to facilitate the estimation process the same way you would do, say in a Planning Poker.
< 1 2 >

Please login or join to reply

Content ID:
ADVERTISEMENTS

"The radical of one century is the conservative of the next. The radical invents the views. When he has worn them out, the conservative adopts them."

- Mark Twain

ADVERTISEMENT

Sponsors