Test manager too busy to get acceptance criteria written before sprint starts

Question

We are about to start a new project that is expected to be over about 8 weeks of 2 week sprints. We are attempting to implement this in an agile manner and so we have recently had a sprint planning meeting.

During this meeting we identified the stories to be implemented in the first sprint. Towards the end of the meeting I asked our project manager who is also acting as the primary tester if we could have the acceptance criteria written before the sprint starts (for the first sprints work). She gave me a strange look and said "na, that's not going to happen". Apparently she is too busy and won't be able to do this in time. They may be available towards the end of the sprint if we are lucky.

In agile, how important is it to have the acceptance criteria spec'd before the sprint starts. Should I push back and suggest the sprint is delayed until these are available, or just go with it and accept they will be done when they are done?

Answer 1

It is not mandatory to have the specs before start, but it helps a lot clarify the details and sort out misunderstandings. Actually, the point of BDD - this is what you are doing - is to start the conversation between the "customer" and the development team(s).

In case the PM has no time to do it, you can do it on your own and ask for a weekly review session preferably before the sprint planning. During these sessions you can clarify all the points you have to have a successful and accepted delivery. Remember, the point is to have the conversation not writing the actual tests, because anybody can write acceptance criteria, but only the "customer" has an idea what she wants.

Maybe after a couple of sessions she will start to feel how good these conversations are and how much extra work you save for the organisation with a quick session. Of course, you'll need to prepare for these sessions.

Answer 2

Having the acceptance criteria defined before the sprint isn't necessarily a fixed requirement, but it would be common for it to make up part of the teams "definition of ready" for any work going into the sprint.

Where you cannot get agreement on something like this and it seems the other party is unable and unwilling to give you what you want there is one good option. Wait for it to come up in a retrospective. One of the benefits of an agile approach is you are continually trying to improve. Right now you think that this is an important thing to get in place before the sprint. Your PM disagrees. So, start sprinting and at you retrospective review what worked and what didn't. If the acceptance criteria don't come up then there are obviously better things to be spending your time fixing. If they do, the PM should then see the impact of not having them in place ahead of the sprint and should want to fix it.

It also sounds like you might not have a DoR (definition of ready) yet, do you have a DoD (definition of done)? If not, having a session to define that with the PM may be an opportunity to bring up the DoR. I doubt it given the flat refusal to give you what you need and their time pressure but possibly if they get input to the DoD maybe they will feel more open to agreeing to have the acceptance criteria in the DoR. Maybe that is a session to run once this comes up in a retrospective.

Answer 3

In GENERAL, Agile is fundamentally about principles, not rules or roles.

The most important principle is delivering what the customer requires, when the customer needs it ... acceptance criteria are kind of a big deal.

The work has to be reassigned or delegated without blaming the overwhelmed resource. When Lead or Project Manager is overwhelmed, she has become the Critical Chain (see ToC PM book, ) that has to be optimized.

Practical Agile is often about suggesting "outside the box" ways to relieve or distribute the burden on the Critical Chain. Gently step up and quietly lead -- do not allow a hero, even a project manager, to take on too many roles and duties and sabotage the whole team's effort.

Answer 4

You are Supposed to have the acceptance criteria or even the tests written before a task even goes on the board.

However we all know this never happens. You can either write them yourself and email for confirmation (although this is somewhat passive aggressive) Or just go ahead and code what you think is required and accept that there will be bugs.

I recommend the second approach. Lets face it, working out the acceptance criteria is usually the hardest part of writing a system. If no-one else can work them out, then they aren't going to blame you for taking a best guess.