If you’ve been involved in software development for any period of time you already know that estimating projects is a difficult problem.  Of all the projects I’ve worked on over the years I can only think of a handful where we came close to getting the timing, the cost and the scope close to the original estimates.  There are plenty of reasons for this, scope creep, team dynamics, planning, domain knowledge, poor understanding of the requirements ….. the list is practically endless.  Humans are just not biologically predisposed to work in absolute estimates.  Some are better than others – especially if they understand the problem – but most of the time we’re just wildly guessing how long the work is going to take and then making the team stick to that. Which is often very painful for everyone involved. This approach is also not a great way of keeping and growing your talent.

Time, Cost and Scope

We have three constraints, namely time, cost and scope.  In a fixed estimation world,  one of these has to give when it looks like the project is going off the rails. Either we change the time we take to get it done, or change the cost by adding more resources or we reduce scope.  This unsolvable problem has led to all sorts of attempts to fix it, such as months of requirements analysis or prototyping or endless change request forms to make sure the consultants get paid for the work.  But in the end someone is left holding the bag. Maybe it’s the developers or the testers or simply that the customer just doesn’t get what they want even after months of requirements sessions.

MVP

But there is a better way.  Just assume that you don’t really know what you want and start working on the *simplest possible* minimum viable product or MVP.  Work with the customer or product owner to list what features you need in your MVP trying all the time to keep it really is simple or lean.  And it turns out that we humans are much better at relative estimates.  We can tell how tall a building is relative to another building and we can tell how long something is probably going to take relative to the other tasks or features in our MVP.  Use T-Shirt sizes, e.g. small (2 points), medium (4 points) and large (8 points) in your estimates to define how many story points each feature is going to take.  Then add them to the sprint.  Show the customer your work and ask what would they like to do next.  Wash, rinse and repeat.  Over time as the sprints are completed the application evolves into something the customer actually wants.  The team has much less fear about meeting the project deadlines and there is typically lower stress and tension during the development process.

Agile Transformation

If you work in a small organization then moving from Waterfall to this Agile process is a relatively straightforward transition.   It works especially well for a series of short projects as over time a well coached team figures out what will make them more efficient.  Unfortunately it’s not as straightforward for larger organizations.  The mindset is and has always been, how much is a project going to cost and how long is it going to take. How on earth do you change that?  We’ve seen many attempts where the company starts with the right idea but inevitably falls into the Agilefall trap where messaging is Agile but in reality the process is Waterfall.  There are several approaches that can help break this vicious cycle.

Timeboxing

The first is timeboxing. Agree on a budget and based on the number of resources divide the budget into a fixed number of sprints.  Push the app to production after each sprint and adjust the features based on the feedback from your internal and external customers.  This continues until the last sprint.  This is a paradigm shift in most companies and inevitably we hear the question – but what if I don’t get what we want when the time runs out?  The answer is that it’s not working now, you’re not getting what you want at the end of a project and if you take this approach you’re going to closer to what you need.

Plateaus

The second approach is based on the Agile estimation we mentioned earlier and only works after you’ve gone through one or two timeboxing projects and everyone is working together as a team.  Before each sprint the team chooses how many t-shirt size points they’re going to try to finish. New teams don’t always complete the estimated number of points, sometimes less work is completed and sometimes more points are completed.The goal is to get to a constant velocity, so that they’re completing about the same number of story points each sprint.  Initial sprints will probably vary wildly and if and when the team jells it’ll start to plateau.  Every team will be different but every team has a number of story points where they plateau.  We use this velocity to get estimates for the stakeholders.  So at the end of the day by not doing hard estimates we find a way to back into an estimate. It won’t be exact but it will be an estimate of the relative time it will take a team to complete a project.

Email sales@riis.com to find out how we can help you agile estimation