[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

-T

T,
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.
Best,
ps

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

  1. Amit Dixit
    February 10, 2012 at 3:38 am #

    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.

    Thoughts?

    • peter
      February 10, 2012 at 8:27 am #

      Right. Exactly. It depends and you have to be very careful about how you split up teams. I’ve seen it work, I’ve also seen it not work.

  2. neil killick
    February 10, 2012 at 4:36 am #

    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.

    • peter
      February 10, 2012 at 8:26 am #

      Right… how do you sell that to the business? “We’ll know after 2 months or so when we’ll be able to deliver… we’ll keep you posted…”

      • Neil Killick
        February 10, 2012 at 4:47 pm #

        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.

Trackbacks/Pingbacks

  1. [Email] – Short Projects and Estimating Velocity | Agile | Syngu - February 10, 2012

    [...] 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 [...]You just finished reading [Email] – Short Projects and Estimating Velocity! Consider leaving a comment! We run our blog on Standard Theme. Be a writer for us. Post a job with us on Agile Jobs. [Email] – Short Projects and Estimating Velocity    Agile Read the original post on Agile Scout… [...]

  2. Retrospective 71- Agile Coach, Transformations, Biz Roles | Agile Scout - February 11, 2012

    [...] Estimating Velocity? – Email [...]

Leave a Reply