How to make realistic long term time estimations when adopting Agile methodology?

Question

I just started to manage the technical department of a small web design firm.

It's the first time I'm faced with such a job and I'm trying to figure out how to improve their project management practices, which now are reduced to keeping long lists of to-dos scattered around a number of internal and client e-mails.

I'm opting for gradually introducing an Agile approach but I have some doubts:

• how do you estimate in advance the amount of new projects to be brought in in the long term when using an Agile methodology?
• how do you manage client's time promises/expectations with agile (especially if you need to do some bug fixing in the meantime)?
• does it make sense to have an agile approach and use tools like gantt charts at the same time to have a longer period perspective?
• do you have any strong suggestion on a software to adopt for managing the projects?

Answer 1

Estimate story points and apply a velocity range

Here is the simplistic arithmetic:

• You use velocity (in story points) as a measure of how much work you can accomplish in a unit of time (sprint).
• You estimate the size of the project in story points.
• Based on these two numbers, you can assess what commitments you can make for future delivery. For example, you can say something like, "I have 5 sprints worth of work on hand (already committed). This new project that is under negotiation is 2 sprints worth of work. So, I think I can commit to delivering this 7 sprints from now."

However, in order to implement this simple model, there are many prerequisites:

1. You need velocity numbers over a reasonable period of time. Minimum is three sprints, more is preferred. Even if you do have velocity numbers over several sprints, it is recommended that you use a range rather than a precise looking number ("Our velocity is between 25 and 35 points.").

2. The harder part is to estimate the story points for new projects under negotiation:

   • You may not have enough details to be able to estimate story points well. In one of my previous companies, all we would have at that point were some bullet points. These, may be, could become epics.
   • You may be already familiar that in Scrum, the story points should be estimated by the team that will actually do the job. Preferably using a process such as Planning Poker. Even if enough details are available to write the stories, the dev team may be bogged down putting out today's fires. And may not be able to spare the time to do Planning Poker for a project well in the future. In my experience Planning Poker gives very good results, but is very slow.

Hopefully this helps to point you in the right direction. Here is a link that can lead you to additional material on this topic: Agile Estimating and Planning

Answer 2

First of all, why are you adopting Agile?

Remember, Agile is a methodology, and as any methodology, is a means to obtain a result. I may be wrong, but if you're expecting Agile to solve all your problems only for being Agile, you're going to have a bad time. You may be addressing a symptom without dealing with the disease. If you try to go Agile only on your IT side and keeping the same ol' agreements with your stakeholders, you may put yourself in a very complex situation. Or you may not. But be prepared, it might not be easy.

Having that said, your job is to manage expectations. How to estimate big projects? You don't. If you go Agile, you can break down the long term plan into smaller pieces and go Agile over these minor deliverables, where you could provide more certainty and confidence to your stakeholders. You give a high confidence estimate for the first deliverables, and then provide further estimates with less confidence for future deliverables. Needless to say, estimates are NOT dates your team will commit to. They give a high level view of the effort required. As less confidence, as bigger the variation over the given estimates.

These projects are likely to have different views, depending on each stakeholder. In my case, I'm used to use a Kanban board with my IT team and keeping the Gantt to 'speak the same language' of business stakeholders. They're only interested in two things: if we are on track and when are we going to finish... and in this case, the Gantt gives them a bit of comfort (as they're used to it). But again, if you go full Agile, you could provide a similar view using burn down charts... I'd just make sure to have this 'transition' incremental to avoid big impacts (and fear from the unknown).

Disclaimer: I'm an Agile newbie (my project is not even Agile, as you see I'm using Kanban), so take my advice with a grain of salt.

Success!

Answer 3

These are not so much questions about Agile methodologies, but of estimation skills generally. Thinking outside IT for a minute, what if you were an oil company trying to decide whether to exploit gas fields instead of oil fields based on where the oil price might go in the next 40 years? Or maybe you work for a government department that needs to estimate the demand on its services five years from now?Or an insurer who needs to figure out the best premium for a particularly risky but high profile new customer (like a life insurance policy for Evel Knievel).

All these decisions involve a fair degree of uncertainty, yet these businesses have a tried and true approach to quantifying and dealing with that uncertainty - probabilistic risk estimation. If you want to learn about it, a great place to start would be a book called "How to Measure Anything - Finding the Value of Intangibles in Business" by Doug Hubbard. I stumbled across this book a couple of years ago while working at a large oil company and it was a total revelation. I try to apply its principles whenever I'm allowed to, because it means I can generate much more accurate estimates than the people around me!

The techniques do require some application of basic statistical analysis and Monte-Carlo simulations, but Doug explains that fairly well in the book, so it's nothing to be scared of. I do get a lot of resistance from my IT colleagues when I try to introduce these methods to IT estimation though, so be prepared for that. What's fascinating is when those people work in the same building as the non-IT estimators in the business, but insist that probabilistic techniques can't be applied to IT projects (totally unaware of the fact that they are applied to the much larger and less certain core business estimates/decisions because there is simply no other way!).

Re: software, have a look at Oracle Crystal Ball or Palisade Decision Tools - Decision Tools is a lot prettier and has MS Project integration, but also costs about 5 times as much. But that's still a tiny cost compared to the potential savings to someone in your situation. The oil company I was working at uses Crystal Ball heavily - pretty much every core business decision gets modelled through it.