We say to our customers that we apply an agile software methodology to our projects, and tell them about its advantages: environments and requirements change and our way of working should accommodate this. We focus on the most valuable features for a minimum viable product and seek continuous feedback for further iterations to maximize the value of the product we build. And we stress the fact that we avoid doing big up-front specifications – because what are they worth when they are outdated a couple of months into the project? Big up-front specifications also generate a lot of overhead to manage changes to the baseline requirements.
“Sounds great” is a typical response from our customers, which is eventually followed up by three inevitable questions:
- When will you deliver?
- What will it cost me?
- …and what will we get in that time period for this amount of money?
Answering these three questions is a very difficult task, especially at the beginning of the projects. Trying to do this leads us on a path to doing big up-front specifications, which we believe is counter-productive to the goal of the project. Instead, we try to answer two of them and asks the customer to trust our way of working on the third.
Let’s assume the customer has a fixed budget and a clear ambition of a release date: Question 1 and 2 should be pretty straightforward to estimate with good confidence: In most cases, we put on a predictable amount of resources for a predictable time period. It is when you put the third question into the mix that it gets complicated.
This is how we try to do it
- We develop a concept for a product, along with high-level requirements as in user stories and sketches for UX design.
- For each of the user stories, we estimate the relative size of each story by assigning a story point to it, which is a lot easier than estimating the number of hours.
- We outline a plan for sprints, which gives us the number of chunks of work until the end of the project.
- We estimate how much work (in story points) we think we can deliver per sprint. This is our initial velocity. At this point, we would have an idea if the scope is way off or within the frames of the project.
- We distribute the stories in sprints and make sure not to exceed our predicted velocity per sprint.
Based on this, we can tell the customer that we will work within the agreed timeline and with a defined team. Based on our initial estimate, we believe we can deliver these chunks of functionality. But after a month or two, we can provide a much better estimate and plan accordingly. We can do this because we will have calibrated our velocity based on our historic progress. This is the best proxy for our future progress. Our story points capture the uncertainty for future requirements, and they would be just as much off as the ones already delivered.