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.

Certified Agile training is vital, but certification alone won’t make you an expert

Certified training has become extremely popular within software development, as candidates are more willing than ever to learn and expand their knowledge. In addition, as technology evolves so quickly, training courses must adapt and evolve to accommodate these changes.

Some people feel that certified training is nothing more than a tick-box exercise and only has limited value. Whilst I don’t agree, I do feel that enrolling on a certified training course is not enough on its own if you’re serious about becoming a respected Agile practitioner.

I don’t want to devalue the importance of recognised and established certification programmes. Having a globally recognised certificate is important; it demonstrates not only your ability to learn, but your desire to educate yourself at the very highest standard.

The ideal scenario is to start with a brief Agile change plan, outlining what your roadmap is. Become certified with a suitable and relevant Agile training programme and then apply the knowledge you have learned from the classroom to some real case studies through workshops and activities.

Agile Coaching

Consistent Agile coaching is encouraged throughout

The important element is having a coaching layer running throughout your Agile journey. This adds much needed consistency, and having the experience of a seasoned Agile veteran to help guide your transition can become invaluable. Agile places value in people over process, after all.

You’ll likely have a slightly different change plan and roadmap, but if you take this proven approach as a guide, you’ll have a much better chance of making your Agile transition a successful one; not just for you, but for your team and your organisation.

Certified Agile training should be treated as your starting point – something to engage your brain with the fundamentals, before utilising workshops and the support of an Agile coach to apply your knowledge and add real value to real projects.

The bottom line is simple. Certified Agile training is an essential ingredient to your professional development and Agile journey. But as with any great dish, it’s only part of the recipe.