Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am new to Pivotal Tracker and trying to learn how best to use it for our business. We are an app development consulting services firm. As you guys know, clients want to have an idea of total time and cost before they sign any contract.

How are you guys mapping your project on Pivotal to total hours and timelines? Any best practices? Pointers?

Right now my team and I have broke the project into stories (love how Pivotal gets us thinking on a much lower level) and have roughly mapped out points to hours.

  • 1 - 1 hour
  • 2 - 2 hours
  • 3 - 6 hours
  • 5 - 10 hours

Then we are basically thinking of 2 as a quarter day, 3 as 3/4 a day, and 5 as a full day or a bit longer.

I then calculate how many 1s, 2s, 3s and 5s we have to get a rough estimate of total hours. Pivotal gives me an estimated completion date based on default velocity (I know this can change). I then report the rough total hours, cost, and due date to my client. I do understand that this is agile and iterative where things change, but when people hire you as a consultant they want costs up front.

share|improve this question
2  
They don't want the final cost up front. They want an idea of the range of costs. Agile allows them to stop paying after any given release. If you want The Number, you're in the wrong business. What kind of information do you want? What will you use it for? Can you clarify what you're trying to do with this estimate? –  S.Lott Jan 12 '12 at 17:49
    
Exactly! That is what I mentioned in my question. They want an "idea" not an exact estimate. My client understands the process of an iterative development cycle and that spec changes will happen and it will extend both cost/duration. What I am trying to do is come up with an estimate based on how Pivotal Tracker is structured and what others are doing to arrive at such estimates. The estimate is really for the client to get an "idea" of what the project could cost and when it might be completed. –  Anand C Jan 12 '12 at 19:36
    
So. You have an idea that you can give them. What's the question? –  S.Lott Jan 12 '12 at 19:36

2 Answers 2

Basically you are trying to do both Agile and Waterfall at the same time which is a bad idea.

This is detailed here: http://www.halfarsedagilemanifesto.org/

share|improve this answer

You're attempting to repurpose an agile project planning tool into a waterfall one.

I'm no expert, but this is the very problem that Agile intends to address i.e: "Responding to change over following a plan". "Going Agile" involves something of a tradeoff - exhanging concrete costs and deadlines for flexibility and responsiveness of development. In a nutshell, the customer has to be (delicately) asked the following question:

Which of these is more important to your business, the features or the delivery/cost?

NB: This is an abbreviation of a commonly accepted rule of thumb, see Thomas Owens comment below re: project management triangle. I chose to present a slightly more cynical slant on it...

Inevitably, clients want both, but armies of burnt out developers/agencies shows that up front estimation rarely matches the reality of execution and generally this leads to hideous overtime or "late" delivery and angry clients.

The whole point of Agile is that it is an attempt to bring an element of empiricism to delivery dates, measuring performance in terms of velocity relative to "task complexity". IMO the problem is that you've equated story size with hourly estimates. The meaning of story size is entirely dependent on how you break them up, which is why 1-5 is not already presented as a unit of time (unlike typical estimation tools).

If they absolutely need a concrete estimate, then they are not ready for an Agile relationship, so use the time honoured method of padding out of your schedule, and hope that the competition is putting in more padding in than you.

As I said, I'm no expert, but I've been through a experience to the one you're describing, and I asked a similar question then too: Funding Agile Projects

EDIT: JFTR - I heartily endorse Pivotal Tracker, we used it extensively on the last project I worked on, but it was something of a paradigm shift for the management/sales team to get their head round...as illustrated by the thread above, Agile is not such an easy sell outside of the dev/enterprise community

share|improve this answer
1  
The question that you pose probably isn't quite right. According to the project management triangle, only two of the sides (cost, time, scope) can be set. The third side is dependent on the other two. Clients want all three - low cost, fast delivery, all requested features. But that's not possible. –  Thomas Owens Jan 12 '12 at 18:18
    
thx, I know about the "cost vs time vs quality" triangle, but phrased it this way since clients tend to fall into two categories, those that want it cheap and fast, and those that want something worth having...but I'll amend the answer –  sunwukung Jan 12 '12 at 18:26
    
Thanks guys! In our case the client thoroughly understands iteration and what that means when features changes and how that relates to cost and time. But when starting any project, people want a ballpark estimate of duration and total cost. It does not have to be concrete, but they want something. I totally communicate that some things could take longer and that new features add to the cost. However estimated total cost and time are are most always asked up front. –  Anand C Jan 12 '12 at 19:14
    
Then work it out the traditional way, get your devs to review the backlog and assign estimates, double it and use PV to track weekly deviation from that figure... –  sunwukung Jan 12 '12 at 20:05
1  
However I do love how Pivotal Tracker works and really wanted to incorporate it into our process. Sometimes a clear deadline drives focus. There are times you need a feature out before a big conference so your sales team can sell the new product features. But at the same time, I think progress is also an important measuring stick, which in the case of Agile is related to Velocity. –  Anand C Jan 12 '12 at 20:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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