[Email] – Short Projects and Estimating Velocity

Hi Pete,

I have a question for you.

My IT department have what you would classify as a small pool of developers, architects and testers. As projects come along people are put on the projects – it can be a simple case of who’s available. The projects are typical quite short 1-5 months. Some developers are regularly pulled off on support tasks.

I feel short projects make calculating velocity almost pointless when the teams change. By the time you have a good idea of velocity the project is almost done. In addition, people (management) always want to know near beginning of a project when it will be finished. With this in mind I have been using ideal days rather than story points to size items on the “backlog” (release scope).

However, I’ve discovered of late that some developers can’t estimate very well. They also change their estimates dramatically when managers start questioning their estimates. Getting detail on some requirements can take weeks – either the true customer is not available or the feature requires investigation to know what’s feasible.

Can Scrum or another Agile technique work in such an environment? Am I flogging a dead horse?

BTW: Are there any good forums that can answer similar questions in an anonymous way?

Best regards


Very interesting conundrum you have there. Interestingly enough it’s not uncommon.
If it were up to me I would do the following:
  1. Create or build out a matrix  according to a dynamic range of skill sets that your development department has. Do you currently even have a good visual overview of hat types of developers you have?
  2. You may be able to break out teams based on their ability to deliver certain things. Such as, an infrastructure team, a front end web team, or a business intelligence team for example. That way, if possible, you can keep the teams somewhat static.
  3. I would ask your management if they would like to have consistent teams deliver reliably. If the answer is “yes” then let them know you need A) consistency of team makeup and B) Little interruptions to that team away from primary delivery functions.
  4. I would fully do a release plan for each project. Wallboard it out with all the epics and features of that particular project. Elicit from your stakeholders what the highest priority items are and their value (if they have that information). Do preliminary estimations on the top priority items and forget the rest for now. Understand (within reason if possible) how long it will take to get the top items done. Start there and iterate as things get complete.
  5. Again, stable teams with little change can create the consistency your business requires that will in turn create some semblance of predictability. Without stable teams, you’ll never get past Storming per Tuckmans Model.
Make sense? As for anonymous questions. You can always do Yahoo Questions… but StackExchange is the best, but you won’t be anonymous.

7 Replies to “[Email] – Short Projects and Estimating Velocity”

  1. Pingback: [Email] – Short Projects and Estimating Velocity | Agile | Syngu
  2. Just a thought here. Breaking teams based Feature/Infra/Etc — may create dependencies amongst them and may result in incorrect behaviour as far as Agile is concerned.

    Example –> A Feature may involve work realted to both web / infrastructural components. If we go with teams based on their specific delivery function, we might end up the Feature in story which may directly not add business value and create dependencies amongst the team. This slows down / delays the delivery of value to customer.


  3. People are terrible at estimating, plus there are too many variables affecting their accuracy. The solution? Don’t estimate at all. Use data to predict delivery date.

    After each sprint you can project out how many stories will be completed by simply counting how many have been done and applying standard deviation. After 3 or 4 sprints you will have a decent indication of delivery date.

      1. Not at all Peter. On day one you will have some semblance of a backlog of stories. On day one the team can make a gut feel estimate of how many stories they can get done in a Sprint (or even better than gut feel if they already know from a past project – remember teams typically split stories down small enough at implementation time to fit into a Sprint, which naturally normalises the rough size of stories). Use that as your initial estimate (i.e. total number of stories / predicted count for Sprint 1 = predicted number of Sprints).

        Then as you start to move through Sprint 1, 2, 3, etc., your prediction becomes better because you are applying real data which, along with allowance for error (standard deviation) will give you an acceptable prediction of delivery date. And the team no longer has to make estimates because the story count tells the tale.

        As to how to sell to the business? Well, I would sell it by saying that I want to remove as much guesswork as possible and use real data to make predictions, and in my experience story count is as good if not better a predictive tool than story points and certainly time.

Leave a Reply