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?
  • 6
    "How to make realistic long term time estimations when adopting Agile methodology?" - in software development you can't, it's as simple as that - with or without Agile. The difference is that Agile acknowledges this and is totally honest about it, while the "traditional" way is to try and pretend the opposite as long as possible. Commented Nov 22, 2014 at 20:27
  • @PéterTörök With relatively small experience (7 years) I agree. But I want to figure out if I can improve my team's ability of prediction. I'm in the web-design industry and sometimes the minimum valuable product looks like the completed website. So as I have many in the works at the same time I need a tool to be able to have an updated overall picture of expected delivery times, to be eventually able to comunicate in advance to the client if a product is going to come out late or re-prioritise work depending on client needs (fairs or similar).
    – mettjus
    Commented Nov 23, 2014 at 1:01
  • Please ask one question per post. If your question is put on hold as Too Broad or for any other reason, feel free to edit it, and ask to have it re-opened.
    – Todd A. Jacobs
    Commented Nov 23, 2014 at 16:48

3 Answers 3


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

  • This is pretty much the only answer. Any other answers will be a flavour of this in some way with some additional guidance. Good points estimation + Sprint velocity = portfolio planning with a degree of error. Commented Nov 24, 2014 at 19:24
  • I think having the team be able to give time/effort estimations without pressure is one of the most important aspects to get as close as possible to a reliable prediction, so I'm always giving the estimations the teams gives me (also thought of Planning Poker, but I'll see if it's the case).
    – mettjus
    Commented Nov 25, 2014 at 19:04
  • The whole Story Points thing makes me wonder a bit: I use story points to hide away the real time estimations but what they actually represent is time. I'm not saying it's not an interesting approach but just I'm not sold yet. Right now I'm keeping my estimations in days-hours-...
    – mettjus
    Commented Nov 25, 2014 at 19:07
  • On the Story Points: I guess they should be useful to decouple time from estimation, so I can get to a "time per storypoint" (which I think is what is called "velocity"). But in the back of my mind I'm still using time to estimate storypoints. Am I wrong?
    – mettjus
    Commented Nov 25, 2014 at 19:10
  • If you have a follow-on question, use 'Ask Question' link rather than as a comment in an existing thread. You can read more on story points vs hours here Story Points: Why are they better than hours? Commented Nov 26, 2014 at 13:21

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.


  • Thx for the clear answer. I'm leaving it open for a while just to see if other answers come in. I posted a linked question here.
    – mettjus
    Commented Nov 23, 2014 at 0:54
  • 2
    To set one thing straight: Kanban is just as Agile as Scrum or XP. Agile is more of an umbrella term or philosophy. Commented Nov 23, 2014 at 12:57
  • 1
    +1 to @BartvanIngenSchenau. Most Scrum teams also use Kanban. The distinction between Scrum and Kanban exists largely in agile purists minds. The Kanban Board is a staple of almost all agile environments and forms the cornerstone of most agile management software packages. Commented Nov 24, 2014 at 19:22
  • 1
    So, I'm more Agile than I initially thought :P
    – Tiago Cardoso
    Commented Nov 24, 2014 at 19:55
  • Especially as a newbie I'm not a purist, so I agree with the combined use of Scrum + Kanban (I just think Kanban is a conceptually easier technique to introduce). In fact I just don't understand why in Jira it looks so difficult to mix the 2 styles. I'm absolutely in favour of an incremental transition because a) I'm no expert and b) something is better than nothing... (eg. total mess)
    – mettjus
    Commented Nov 25, 2014 at 19:01

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.