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.

Just how Agile is Santa?

Santa only knows how to do a “big bang” delivery. At first glance, it’s easy to suggest that Santa isn’t very Agile at all. But the more we inspect his actions leading up to the big day, it’s evident that he’s been reading an Agile blog or two.

We can’t fault Santa for his Just In Time techniques. He only asks for his requirements a few weeks before delivery, giving his millions of stakeholders plenty of time to figure out what their highest priority items are. And they’ll inevitably change frequently.

You might view Santa’s approach to requirements gathering as succinct. Whilst it is true that there is often no clear definition of done and some gathered requirements can be vague (I always used to ask for “some surprises” at the end of my list), it’s great that he takes it upon himself to talk directly to his customers. Many modern implementations of Agile rely on a proxy Product Owner, often meaning that the development team never communicates directly with the business.

Self-organising teams are fundamental within the North Pole workshop. We’re all well aware by now that Santa’s workshop is filled with cross-functional and multi-skilled little elves, all working together and co-located. They’re trusted to do a job and empowered to get things finished in time for delivery; whatever it takes.

I’d like to think that every Boxing Day, Santa, Rudolf and the rest of the team sit down to hold a retrospective. If they didn’t do this, I can’t see how else they could continually adapt to the changes within their industry. Continuous Improvement is key within any Agile implementation and without it, Santa today couldn’t do the same job he did 50 years ago given how different the world around him is (think; more children, more advanced toys to make, less houses with chimneys, etc).

Even if your practices are perfected, industry trends could change things in an instant.

Santa operates in a regular sprint rhythm. Whilst his sprints are long, in 12 month cycles, this routine ensures that not only his team but critically his stakeholders all have clear expectations of when they can expect the next delivery. Setting expectations, and meeting them, is key.

So whilst Santa isn’t the perfect advocate of Agile, there are certainly more good Agile practices involved in his tight operation than initially meets the eye. You could argue that the extensive feedback loop is by design, but try telling that to the child that got some eggnog for Christmas instead of the Xbox that they asked for.

Ultimately; the seeing is the believing. And that’s the true magic of both Christmas and a successful Agile delivery.

Insufficient training is a leading cause of Agile failure

As a certified Agile trainer, I was particularly interested to note that insufficient training was reported as one of the highest reasons for the failure of an Agile project in the most recent State of Agile survey.

Some 30% of the respondents to the survey said that they blamed insufficient training for failed Agile projects; a humbling fact when you consider how simple this problem is to solve with a little investment.

Further scrutiny reveals that insufficient training can be broken down into one of three categories:

  • Nobody received training
  • Not everybody who needed training received it
  • Some received training, but the training wasn’t very good

Nobody receiving formal training is unfortunately all too common, especially within companies who may not have a dedicated training budget to utilise. It normally falls on whoever last picked up an Agile book to educate the rest of the team; often leading to disaster.

Insufficient training is amongst the leading causes of Agile failures

Insufficient training is amongst the leading causes of Agile failures


The wider team not being trained happens all the time. I’d wager that within the vast majority of Agile teams, only the Scrum Master has received any formal Agile training. Whilst the Scrum Master training course is fantastic, what about the rest of the team? Training courses such as the BCS Foundation Certificate in Agile do a much better job of educating everyone involved in the process instead of isolating specific roles.

Finding the right training supplier is often critical. My experience has showed that large training organisations who offer hundreds of different off the shelf courses can often provide much less in the way of value, than if you were to work with a company who specialise in just Agile training.

If you’re serious about an Agile transition within your team, ignoring formal training isn’t the right approach and will never lead to a successful Agile organisation. It’s important that everyone involved in your Agile efforts receives relevant training and it is wise to invest in training early. Not only will it give the team the knowledge of Agile techniques, but also an understanding of why it is the better approach.

You can download the State of Agile Survey here.
You can find out more about the BCS Foundation Certificate in Agile here.