# Estimation given in days and need to plan in Agile

The client internally feels that this is about 500 developer days worth of work and there could potentially be 4 developers (or pairs of developers) that work in parallel. We need to go back to them with a proposal work in agile. Later on if new work comes up it will be taken up accordingly.

But the point is how to plan for this in agile.

Should I take

• 1 day as 1 story point ,
• 1 Sprint = 2 weeks.,
• Velocity = 16 story points (4 people * 4 days),
• 1 release = 3 sprints,

And calculate accordingly??

I don't have total of story points. I just have total developer days and now I have to estimate.

• If you try to equate story points with units of time for planning purposes, both you and the customer will experience mind-boggling sadness and despair. Oct 11, 2015 at 7:00
• I agree...But customer is not agreeing so how should I take care of this scenario Oct 11, 2015 at 7:09
• This should answer your questions: pm.stackexchange.com/questions/16372/… Oct 11, 2015 at 8:08
• How does your client estimate your work? If your client is convinced it takes 4 developers and 500MT, then you don't need any estimation, your client already did it. Oct 11, 2015 at 9:50
• Is there any reason your developers couldn't give estimates in days? As long as the client understand what an estimate is (and more importantly, what is NOT!), you could go on have your devs providing estimates in days. Seems both you and the client isn't used to use SP, and trying to add them would only cause more headaches and frustration for both. Oct 15, 2015 at 18:36

Take your 4 developers, give them the backlog, let them do a high level estimate for each story (or epic) by complexity (using story points if you like, but NOT days). Then take a possible sprint backlog and see how many stories could possibly fit into a sprint. Repeat this for at least 3/5 times with different backlogs. This should give you a rough idea of a possible velocity per sprint. Now take the number of Story points for the whole backlog and divide it by the velocity and see whenever 500 m/d fits it or not.

Bear in mind that this is a high level exercise (and works only with a fairly defined backlog), do not expect to come up with a precise estimate, nor a detailed plan that fits 500 man/days of capacity. Do not expect to be able to translate story points into man/days, this will soon become a mess for you and for the client. For such an important effort you'd better concentrate on an effective risk-management strategy instead of wasting time doing endless estimations.

• Mamoo...this is actually a good idea but in proposal stage we don't have stories to calculate story points but we will ask them if they give us the option of having "zero sprint" where we can create stories and calculate story points and come up with a high level plan Oct 12, 2015 at 5:03
• @DimpleSahani: How can you give any estimate (or agree with the 500 man-day estimate that the client gave) if you don't know what needs to be made? Oct 12, 2015 at 8:40
• They are an old client of our company and they have given high level details....generally in proposals we get back with estimates based on details given but here we have trust relationship with client...requirements are with us but they not detailed enough that we can create stories and decide on story points...that's why Mamoo's suggestion seems to be good to us and we can talk about sprint zero and anyway the Cost will be TnM where resource cost will be monthly basis and not fixed price...so cost risk will be mitigated Oct 12, 2015 at 9:52
• Your developers are probably pretty smart and you say you know the customer well. Have your developers use Jeff Patton's Story Mapping exercise to come up with what they think the stories should be. Then go through Mamoo's exercise. Oct 13, 2015 at 1:15
• Joel Bancroft-Connors, I am not aware of Jeff Patton's Story Mapping exercise - I will check this out and will ask you if I have any question Oct 13, 2015 at 5:30

Constraints

If you've been constrained to 500 days, essentially you already have your estimate. Your client has time-boxed your activity. Time-boxing is a common (and Agile way) to set a budget.

Now, if we take the 500 man days as our budget, then assume we'll have 4 developers (equating to 125 working days - assuming no absence), so we've fixed two vertices of the cost-time-quality project management triangle:

So, we're left with scope as the only variable for our product - this is where estimation comes in. We need to ensure that what you'll be able to deliver within those constraints will satisfy your client.

To do that, you'll need to be able to break the requirements down into high-level stories that you can then categorise (by priority) into critical (MVP), core and optional features of your scope.

Scope

You'll first need to estimate each of the critical stories that will form your minimum viable product. You can start with story-points or other relative sizing activities initially, but you'll eventually have to form an estimate in days of effort.

The temptation is usually to apply a conversion factor from your relative sizing to days of effort (e.g. 3 story points equals 1 day). Don't do this! Instead, use the relative sizing to discuss and refine your work estimates.

Negotiation

Once you have your high-level estimates for your MVP, you'll be able to assess whether the time-box will realistically give your team the opportunity to deliver the client's vision. If the MVP estimate came out at say, 200 days (effort), repeat the exercise for the remainder of the core and optional features.

If the estimate for your MVP, core or optional features pushes the estimate beyond the time-box, you'll need to start negotiating with your client. If it's just the MVP alone that's big enough to break the time-box, you'll either need your client to agree to a smaller scope or increase their budget (which may involve questioning the feasibility of the project)...

If it's either the core or (more) optional features that don't fit into the time-box, the client will need to prioritise them - in the full knowledge that if work completes faster or slower than the estimates, they'll get more or less of these features - but they'll get the ones most important to them first.

Alternatively, you may be able to demonstrate that if they allowed more time / resources / teams, you'd be able to deliver more of what they want:

Delivery

To gain more confidence in your estimates, your client may agree to a few "pilot" iterations (Sprints) - or they may just agree to let your team start the product in its entirety. This is where velocity tracking comes in.

After each iteration, you'll know how many story-points have been delivered. From there, you'll be able to begin tracking and forecasting your burn-down rate. Remember that burn-down is non-linear, so don't treat the estimates your team gave as deadlines, but do monitor the velocity trend. You can use this information to provide clear visibility to your client as to whether your efforts are on track (and manage their expectations or react to any deviation).

• Mikaveli, this is a very good point...I will utilize this and also add this in proposal so that my risk is mitigated Oct 13, 2015 at 18:36
• I totally agree with the first half of this answer, and it shows that scope is the only room you have to flex. Story points aren't a requirement of agile, they are just something that is often applied within agile frameworks. It sounds like you are comfortable enough thinking of the work in man-days - this isn't necessarily bad and I would encourage you to continue to do this if it is most sensible, both for communication with the customer (rather than educating them around story points) and planning work. Oct 15, 2015 at 14:30
• @SpoonerNZ Thanks - it's still something I'm conflicted over, in that there are still external factors (customers, upper management etc.) that still demand an estimate, quote or other commitment in days - so we're forced to use man-days on occasion, but try to avoid it. Oct 15, 2015 at 16:04

Story points are an estimate of the relative size of a user story. They take in to account things like risk, complexity and dependencies.

The idea in using story points is that we do some work within a timebox (i.e. a sprint) and then measure how much we got done. Then we use that measurement to guide our future estimate of sprint capacity. It is very different approach to time based estimating, which is based on guessing how long things will take to do.

Note that the Scrum approach is based on doing a sprint, getting some feedback and then adapting the requirements if necessary. It is not a fixed scope by definiton, instead it is a variable scope that aims to deliver what the customer really needs rather than what they initially believe they need.

My suggestion would be to ignore the 500 day estimate for now. Instead, get the team that is going to do the work to do story point estimates. Then, complete 2-3 sprints and see how many story points you get done. That then determines the teams velocity. Knowing the velocity and the remaining amount of work you can then get a feel for when you might be done. But keep in mind that as you do the work you will be adjusting the requirements in accordance with feedback from the client. As such, the estimated end-date will need to be continually adjusted as the team's velocity changes and as the scope changes.

Clearly you are going to have to discuss this with the client, so that they understand the agile approach and buy in to this way of doing the planning.

• Barnaby..This is the actual way of working, I will try to convince my client on the same Oct 12, 2015 at 5:04

I think forget the 500 days and the story points for now and focus on what you can show to your client. It sounds like you have a high level picture of what they want delivered? And you agree it's probably in the region of 500 developer days work.

So, break down the high level vision into some smaller releasable increments. Ideally into chunks which you can deliver to the client and they can actually start using. Possibly you use this as the main talking point for discussions with them, which parts of the project would be most useful if delivered first and would they then start using them? Make it clear this is the benefit of working with an agile approach, and that it will allow them to course correct and re-prioritise if they discover things should be changed during the development rather than when the whole project is delivered.

You will then need to break down those larger chunks of work (Epics) into your user stories for the team to estimate using story points. Once you have had a few sprints you should hopefully know at least a rough idea of your velocity and can start equating the story points on the project plan to delivery dates. At that point you can check the match between your 500 days estimate and the reality but not before. Getting the client to understand this may be tricky but is critical if you don't want to have to lie to them and give firm time estimates for work which is yet to be estimated by the team. Maybe they will accept your finger in the air estimates and understand they are only estimates and not guarantees?