In a recent article on AgileConnection, Allan Kelly wrote the following about the timing of writing acceptance criteria (acceptance tests) for user stories:
The Right Time to Define
I am frequently asked, “When should we write the acceptance criteria?” Sometimes programmers resist giving an effort estimate for a story unless they can see the ACs—sometimes detailed ACs, at that. However, there is little point in POs (and testers) spending time on ACs until stories are about to be scheduled. After all, if ACs take hours to write and the story is not scheduled, their time is wasted.
Also, if ACs are added but then the story doesn’t get scheduled for a year, by that time the story and the ACs may have changed. Because old criteria are in place, it can be easy to overlook these potentially important changes.
I was talking to the CTO of a company heavily invested in “going Agile” the other day. He was incredibly frustrated.
It seemed they were pouring money into the execution / technology teams – moving from an investment of 9% of revenue to nearly 35% of revenue in R&D. From his perspective, they were hoping that agility would be a creative and productivity “force multiplier” in their space and they were doing everything they could to support it.
However, what he was seeing from his perspective was…nothing.
There’s a trend in the agile community of influencing folks away from saying no, instead saying: “Yes, And…” as a means of connecting various conflicting points together. I wanted to use the same mechanism for the title of this article, because I think we need to start looking at the basic Scrum certifications in a different way, perhaps the same way we view Peanut Butter AND Jelly. Let me try and explain.
I’ve seen an incredibly alarming trend over the last 1-2-3+ years in my coaching. It involves whoever is teaching Certified ScrumMaster classes; whether they be from the Scrum Alliance, Scrum.org, or elsewhere.
I encounter quite a few organizations and many teams in my travels. Almost universally they are adopting Scrum and have a few to many CSM’s around to guide the transition.
But I’m finding that the “Scrum” that is being fostered and guided in these organizations leaves a lot to be desired. Often:
I have a good friend and colleague who works in a rather large enterprise. Among others, she’s tasked with bringing “agile” into the organization and “transforming” their work. She’s largely leading the effort, so has a tremendous amount of responsibility for its success.
They’ve chosen Scrum for this effort.
They’ve engaged a rather large agile coaching firm to help them “go Agile”.
So far their strategy has been along the following lines:
- Hire full-time agile coaches
- Do a little training for “Leaders and Managers”, less than a ½ day, usually 60-90 minutes
- Spin-up Scrum teams (a little training), with Technical Leads as ScrumMasters and limited Product Owners (time and skill)
- Start sprinting
- Hire more agile coaches
- Spin up more Scrum teams…start sprinting
- Rinse & repeat…
To-date, there are more than 50+ newly minted Scrum teams who are dutifully sprinting away creating lots and lots of value.
Chris Waggoner is a friend and colleague of mine. He is a CSC, Certified Scrum Coach, and a very experienced agile practitioner.
He sent me the following snippet in an email that I wanted to share:
"If Agile is a team sport, then the product backlog is the ball." - Chris Waggoner
I'm trying to get a group of PO's to realize that they should not attempt to complete a product backlog on their own but they should seek help at every phase of grooming stories and massaging the backlog. On the flip side I'm trying to involve teams who believe it’s the Product Owners responsibility to bring them a completed, ready to consume story that they to are responsible for the completeness of stories and the state of the backlog. This metaphoric phrase above came out of my mouth and it made sense to everyone once it did.
Chris Waggoner, CSC
Managing Consultant | SolutionsIQ
It was unsolicited, but nicely aligns with my own thinking.
The user story has nearly become the ubiquitous requirements artifact in agile contexts. So much has been written about the user stories, their format, how to write them, the associated acceptance tests, and more.
As for acceptance tests, we’ve moved beyond writing them to articulating them as “executable tests” in tools such as Cucumber and Robot Framework.
All of this evolution has been great, as is the focus on the collaborative aspects of the user story.
But I’m starting to see something troubling in my coaching travels. I think we might be focusing too much on the user story as an agile requirement artifact. Instead, we should be taking a step back and considering the user story as a much simpler communication device.
That is simply as STORY, and much less as a written story, but more so as a story that is told…face-to-face.
My colleague Josh Anderson and I were chatting on the Meta-Cast the other day about agile team sizes. While there are no prescriptive limits or guidelines to agile team size, there are general guidelines.
From Scrum, the size has always been recommended to b 7 +/- 2 (or 3..9 in the latest Scrum Guide) as the preferred size for teams. But as in all things agile, direct experience is always valuable. So what was ours?
This is a guest blog post by my colleague: Chris Waggoner. Enjoy!
Estimation of time and effort until you’re done is one of those things that every inquiring manager wants to know. In an effort to provide “accurate” estimates, companies and people spend countless hours generating list of task and debating the duration of each task. When it comes to developing software these estimates are rarely correct and often grossly wrong. The estimates are wrong because in building software that we are often building something that has never been built before. When we find ourselves being pressured to estimate something we’ve never done we tend to SWAG (PMI for Sophisticated Wild Ass Guess) the answer in man-days and/or hours without understanding or knowing all the potential variables in play. Here in lies the problem with traditional software estimation methodologies: within a short amount of time spent there are diminishing returns on effort versus value. That is to say, early in the traditional process the value of spending more time estimating doesn’t provide a higher certainty of when we will be done.
Over the past few months I’ve been coaching my clients who are in the early stages of adopting agile approaches for software. Most of them are adopting Scrum, but a few are adopting Kanban.
Universally, one of their complaints is that their teams aren’t “stepping up” to the
- Empowerment
- Responsibility
- Accountability
- Passion & Energy
- Creativity
That is implied as part of the culture of self-directed, agile teams.
To say that they are disappointed is an understatement. And these comments are coming from all levels of the client leadership teams.
In 2009 I first published Scrum Product Ownership. In 2013, I followed it up with a second edition. The book has been a popular read for those who are looking for a solid overview of what it takes to be a competent and craft-focused Product Owner.
Here’s what a new Product Owner from Spotify had to say about the book:
“I was recommended your book “Scrum Product Ownership - Balancing Value from the Inside Out” by senior colleagues at Spotify as the one book to read when new to product owning. After recently finishing reading it, I fully agree and will keep recommending your book to anyone getting started as a product owner.
I just wanted to say thank you for making the start of the ride less bumpy and for great advice that I will keep returning to as I gain experience.”
I share this because it helps to set the stage for this article and where my inspiration lies.
