Agile Lawn Mowing Part 1: A Story of Acceptance

Agile Lawn Mowing Part 1: A Story of Acceptance

lawn mower in grass

I love mowing the lawn. Compared to the day job, yard work shows an instant transformation as a result of your efforts. My dad is now 86 and struggling with his health, so I wanted to help him out. His mower is a big, heavy, petrol-driven beast, so whilst it does a good job, it’s heavy to manoeuvre, and I thought he’d be glad of the offer.

So I mowed the lawn, emptied the grass box, trimmed the edges and felt pleased with my efforts. But dad wasn’t. We hadn’t discussed “acceptance criteria” before I started. I’d assumed my own acceptance criteria:

  • Lawn must have nice stripes!
  • Grass must be no shorter than 2 centimeters, or else the grass will die in the sunshine.

Dad had an extra criterion–must not drop cuttings!

As I’d let the box get too full, there were places with a fine trail of cuttings which had leaked out! I could rake the whole lawn or just mow it all again. If I raked it, there was no guarantee he’d be happy, and there was a risk that the stripes would lose their edge.

I chose to mow the whole lawn again, effectively doubling the effort and, in agile terms, halving my velocity.

Conscious Acceptance versus Subconscious Acceptance

Maybe you are already shaking your head and saying, “Ah yes, you should have agreed to the acceptance criteria before you started.”

Well, yes, and that works well for criteria which are conscious. However, it can be difficult to articulate exactly what you want or what you consider acceptable until you see what is not acceptable to you. That is when the subconscious criteria emerge.

For example, on a recent project, we were designing and building a mobile phone app with a feature to capture a photo into a scrapbook. Conscious acceptance criteria covered the size of the image, choosing a picture from the library or using the camera to take a new shot. But it was only when a basic implementation was done in an early sprint that subconscious became conscious and the product owner started to talk about cropping and editing the image as well and handling landscape and portrait differently.

This is where, in my experience, an agile approach to software delivery really pays dividends compared to waterfall delivery methods. On a waterfall style project, I would hear conversations like “That wasn’t in the requirements, so that’s a change request,” followed by “it is obvious that it should be included–that is standard processing for photo capture!” 

In an agile project, sharing as soon as it’s reasonable to share means that when gaps arise, they can be discussed as future backlog items and prioritised in the context of the whole project. In our case, the mobile app was for a health data service and the photo capture was a secondary feature compared to many of the other items on the backlog, and so the product owner consciously chose implementing security around handling personal health data over complex photo editing features.

Unlike mowing a lawn or taking a photo with a phone, many software projects are implementing something that has never been made before, something that neither the product owner nor the team can fully imagine as they are discussing acceptance criteria.  Which brings me back to rapport and empathy and a good relationship between the team and the product owner for delivering the common vision.

Emotional Acceptance

In terms of keeping the product owner involved, I’d sent Dad inside to sit down and have a cup of tea. If he’d been watching me, he would most likely have commented after the first time I dropped cuttings on the lawn, making his subconscious conscious. I’d have been able to adapt sooner and reduce the rework.

However, Dad might not let me mow the lawn again. His experience was that we don’t share the same standards and, although the job got done exactly to his satisfaction in the end, how he felt about the job may still influence him in the future.

For me, acceptance criteria are more than a checklist. They reflect what is important to that person in a wider context. A product owner leaves clues about what is acceptable, and it’s our job as analysts and designers to constantly pick up on them if we want to keep a good relationship and deliver a good project.


Claire serves as Scrum Master and agile coach for global IT services provider Atos in London.

Learn More
comments powered by Disqus