Presenting agile estimates for Pivotal Tracker project

Question

I've been developing for 6-7 years but never in a particularly agile way. With the latest project I'm trying to make our development process more professional, and more agile.

We're using Pivotal Tracker to track the project and have gathered some pretty well thought out stories. We're also trying to keep some of our (Prince2/Waterfall mindset) project managers happy.

So far I've got them to accept that

• requirements always change
• priorities always change
• some of the requirements won't be delivered if you fix the time scale
• you should fix the time scale
• short sprints and regular review is good

However they still feel like they need to get a better grip of roughly how much will be delivered within a certain time.

I've come up with a spreadsheet to demonstrate what we might expect to get done in a range of 4 different timescales.

Questions

• Are we setting ourselves up to fail
• Are there better ways to do this

Answer 1

The danger with this sheet is that can easily be read as a final planning with guarantees. People just overlook the small print (your notes at the bottom). Whereas even the green boxes are no guarantee.

In a project I'm working on we're struggling with the same. We're trying to hold on to not give any estimates; hard but not impossible. We've found a few things.

1. It is very dangerous to give estimations (or even guarantees) when something is done. People forget that you told them that nothing is guaranteed; "why would you otherwise say that it gets done next week?". When you don't make it, people get angry.

2. When people have a date, they communicate that to the outside world (read clients). Then it gives even more irritation when you don't make it, as they have to go back to the external person and say it won't be there (when they need it).

3. It is better, and easier, to give them insight in current progress. A common tool in agile of course is a burn down chart. In our project we use a Trello board, much a like this one. (Here's our Trello board, but it is in Dutch so you might not get everything.) We keep them updated on whether something is worked on and what outcomes it generates. We add notes, interaction designs, graphic designs, screenshots, etc. Sometimes we also ask for feedback or to help test along. This involves people in what is going.

4. As soon as possible, pass on the mantra that the product is already done and just getting improvements over time. This helps people not to wait for a specific moment. This one is most hard when the base of the product is not there yet. Although you have to watch out that "the base" is extended all the time.

No matter how good your stories are, there is a risk they take way longer or won't get there at all. It has happened to us quite a few times that we have to completely rethink a feature; find another solution for the underlying problem; or come to the conclusion that it doesn't have as high priority at all anymore. This all messes with the planning so much, that it is really hard to give estimations.