Estimation given in days and need to plan in Agile

Question

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.

Answer 1

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.

Answer 2

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:

Source: http://www.tutorialspoint.com/management_concepts/project_management_triangle.htm

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:

Source: http://agile-setchu.org/setchu-guide/agile-feature-teams/

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).

Answer 3

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.

Answer 4

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?