Testing estimation within Agile teams

Discussions around estimation within software development are plentiful. Many different approaches have tried – and largely failed – to make estimation more accurate. What I love about estimation within an Agile approach is that the aim isn’t to make the estimation necessarily more accurate, but to find a more suitable measure.

In addition to how you’re going to estimate, the discussion around how the testing involvement fits into your estimates will inevitably crop up. Should you have a development estimate and a separate testing estimate? It’s a subject often misunderstood, and one that to explain properly, we need to explore the Agile Manifesto itself.

“Individuals and interactions over processes and tools”.

The key message here is to not complicate things. Estimation is an art – it’s not something that a catch-all process can help you solve alone. The best estimates, at any level, are those that have been discussed, questioned, debated and finally agreed upon; collaboratively. This can be hard enough to achieve within a group of developers, but when you add a group of testers into the mix as well, you’re dealing with a different dynamic of thinking.

And yet I’ve witnessed so many Agile teams either treat their testing estimates separately, or don’t even bother with them at all. When digging further, the reasons for this often stem from the testing element of a user story being treated as a specific phase, rather than a fundamental part of that story that must be completed for it to be successfully closed. In other words; more value placed on the process than the individuals and interactions.

I personally see testing within Agile projects not explicitly as a “phase”, but an activity that happens as part of every single user story. I’ve seen Kanban boards before, for example, with “Testing” having its own column. I’ve never liked this setup as it helps turn those invisible walls between development and test into reality and encourages an over the wall handover.

Don't treat estimation as just a phase; think collaboratively

Don’t treat estimation as just a phase; think collaboratively

It’s easy to understand why test estimates are a secondary concern when teams run projects this way. This can quickly become a problem when you stumble on a relatively trivial development task that could have major implications on the system; thus involving significant test time upon completion of development. You’ll learn very quickly that just because something is easy to develop, does not necessarily mean it is easy to test. And visa versa.

A collaborative estimation session is essential. To avoid any major imbalances with time (after all, a task might still take longer to develop than to test), we should be basing our estimates on complexity instead. This way, both parties can input into a relative estimate that makes sense for everyone. There are many different techniques to use for relative estimation – far too many to go into detail in this post – but using user story points via the Fibonacci scale is an excellent way to estimate software development and testing tasks.

“Working software over comprehensive documentation.”

Another fundamental from the Agile Manifesto is our desire to frequently produce working software. I’ve worked in this industry long enough to hear a developer proudly proclaim that “it works on my machine”. This is not a good example of working software. To deliver things incrementally, the finished output from each sprint must be fit for purpose and tested within the environments that it will be used. This is another simple reason why the test input to estimation is so critical to a successful sprint.

It should go without saying that testing estimates are important. Like most things, Agile techniques don’t reinvent the wheel and don’t try anything crazy; for the most part, it just asks that you use common sense and focus on the right things.

We’re back to collaboration again and, whilst so simple, it really is the key to a good estimate. Collaboration and a mutual empathy between developers and testers is the only way an estimate can be seen even remotely accurate. Estimation accuracy is an entirely different conversation as I’ve already mentioned, but all we can do in an Agile world is everything we can to measure appropriately.

So ultimately, in its purest form, to run a successful Agile project we should be looking at as many ways to ensure collaborative working as possible. That starts with a vision and then leads to estimation. Getting rid of the internal departmental boundaries that so often surface is essential. Don’t treat your testing as a separate phase, but an integral part of every single user story that should be treated with the same importance as the development tasks that are spawned from it.

Understanding that an estimate is only truly established when the complexity is assessed and agreed on by all parties is the first step to building the confidence we need to make estimates truly valuable, and not just a tick box exercise.

This blog post was originally featured on TestLodge; An online test case management tool allowing you to manage your test plans, test cases & test runs with ease.

#NoEstimates? Get a grip. Sprint level estimations are vital

The purist in me loves the concept of no estimates. Imagine a world where designers could just design until everything looked perfect, developers could just code until everything worked exactly the way they wanted and at the end of it all, whenever that might be, their labour of love is packaged and delivered to the happily waiting customer.

Let’s all take a moment to get realistic. The whole elitist, self righteous attitude towards the entire #NoEstimates movement needs to stop. Would you take your car in for an MOT and tell the mechanic to do whatever work needs completing to meet your goal of passing the MOT without expecting an estimate? Absolutely not. Would you call a kitchen fitting service, tell them what you want your new kitchen to look like and then let them install everything before giving you a price? Don’t be ridiculous.

I’m afraid the same is true of software development. If you think for one moment that any respectable organisation is going to give you a blank cheque and let you get on with the work, then you’re very much mistaken. You shouldn’t frown or tut when asked to provide an estimate because it’s an absolute necessity. Whilst we all understand that software development by its very nature is difficult to size, if you’re confident in your ability and in your process, giving an estimate at the right level (more on that below) should be easy.

What we should be focusing on is not removing estimates from the process, but turning estimates into something that are actually useful. I am under no illusion that education is required to achieve this so that people truly understand what an estimate is, but by trying to cut out estimates you’re just adding to the problem.

We need to be pragmatic. I’m not suggesting for one moment that we should give management a “man days” estimate for a project – that’s unrealistic and would just set everyone up for a fall. In my opinion however, it is realistic to perform a sprint level estimate which has the added benefit of getting your epic user stories in order and into a storymap before you begin. It’s a remarkably straightforward but powerful way of understanding how much work is ahead of you.

Get the entire team, including your Product Owner, together for the day. If you can, go off-site somewhere. Have the PO talk you through the project – the vision, the goal and of course the epic user stories. If you’ve got any supporting wireframes or designs – great. Once you all understand what it is you’re being asked to build, it’s time to revisit each epic one by one and talk it through in a little more detail. Based on what you know, ask yourselves as a team “is this something that can be tackled within one sprint?”. If it’s too big, then break it down until it does fit in a sprint.

Move onto the next epic. “Can we fit this in the same sprint as the last epic?”. If not, it goes into a new sprint. Rinse and repeat. At the end of it, you’ll be left with a storymap of the entire project – based on what we know now, of course. Ultimately this will eventually lead to the team feeling confident about saying that they need around N sprints to complete the work. From this we can create an indicative sprint plan and the estimation requirement is satisfied.

Of course, the usual caveats apply – this sprint level estimation is only based on what we know now and can only take into account the factors that we have considered at this stage. The detail will come in the sprint planning, but this should be enough detail to give both the PO confidence that you understand what needs to be built, and importantly the customer will have an idea of how much they will need to invest into their new project.

We don’t know, or want to know all of the detail up-front and this form of estimation caters for that. Be confident to provide an estimate like this and don’t shy away from it. Make sure your stakeholders understand the level of estimation you’re providing but be realistic when you provide it. Kicking off a project in the right way is essential, and starting with a good understanding of the goal, a storymap and an approximate idea of how many sprints will be involved is an excellent place to start.