As an agile tester, I want to share the status of the project’s testing tasks with my team, so we can solve any issues and impediments before they become bottle necks.
This article will give you an idea of how to deliver test statuses at a daily scrum. The test related work in agile teams seems to revolve around user stories and their acceptance criteria. This will naturally also be the centre of the discussions in daily standup meetings (or a scrum as it is often called).
Here are some of the basic question that I will address in this article:
- What is the basic agenda of a stand-up meeting?
- Which testing activities should an agile tester be planning for an iteration?
- What testing constraints should an agile tester be prepared to meet?
- What obstacles impacting testing should an agile tester be prepared to address?
- What to consider when communicating in cross-functional teams
- The beauty of Failing Fast and sharing it based on trust and shared responsibility
How To Deliver Test Statuses at Daily Scrums so Everyone can Understand It
One of the rules of the scrum is that it is time-boxed, so you don’t get to chit-chat – you have to be concise. Another scrum rule is that each and all members deliver a status including obstacles and next steps within the time-box. It is pretty much like a turn-based game where each player go through the turn’s phases:
- what was your tasks since last scrum
- what are your tasks until next scrum
- what may prevent you from accomplishing them
A case: You’ve been working with a coder on a user story for an email opt-in form on a website:
“As a non-subscriber,
I can submit my email on a landing page,
so I can receive updates through the email marketing channel”
You’ve established the acceptance criteria and the need to do an exploratory test that include an integration to an email marketing provider, but you don’t have the customer’s credentials for the service so you can setup a test environment for the integration. You’ve already collaborated with the coder on the tests and there is a stub that can receive the email.
This is how you’d give your team the status update:
“Yesterday, Coder Bob an I tested the story for the email opt-in form on the landing page with a stub.
Next step is to test that the integration to the email marketing provider actually works.
However, I need the credentials to the email marketing service so I can setup an email-list that can catch the output from the form”
To that, the product owner would naturally answer:
“Sure, I’ll get it for you after the meeting”
There: three breaths of air and everyone on the team knows exactly what you did, what you’re about to, and what holds you back from doing it. You even got a solution to your problem in less than 30 seconds. (I should add that the example story is pretty short and there would be more of the same kind in your status update. Problems of this size could also be solved outside the standup meeting, but for the sake of the example and me not being able to come up with a real problem, please play along here).
In the case, you clearly state your task since last stand-up meeting, your next step, and the obstacle you’re facing. A team member have the solution to your problem and it is clear what has to be done and who will take the next step.
However, what if not all team members know what you’re talking about, even if you speak no riddles?
In agile teams all members have different skill sets, which is good. It is therefore important, not only to be concise but to also provide enough information about an obstacle so everyone can understand it and potentially help you clear the obstacle.
It is a two-way street: if you find yourself in a scrum not understanding a fellow team member’s problems it is your job to ask for just enough details to understand the problem. Don’t babble on or encourage the speaker to do so. Simply raise your hand and ask concisely. To riff on the example, you might not know what an email-list is in the context of email marketing providers. Ask: “What is an email-list”. Everyone at the scrum will know the context of the question and know that you ask because you might have a great solution to the problem if you know more about it.
Fear of inadequacy might withhold some people from asking that “dumb” question. Fear of inadequacy and “dumb” questions simply does not exist in pure collaborative work. You’re already a team member, so you’ve probably been chosen for a unique skill set that fill the gaps of other team members – perhaps even your ability to ask questions in a way that reveal unforeseen issues, in which case it is your duty to practise that skill until success.
- Be concise.
- State what you did,
- what you’re about to,
- and what may hold you back.
- If in doubt, ask
- and ask again.
What is your take on how to deliver test statuses at a daily scrum? Do you share similar experiences or is there a side to it that you think is important? Leave a comment and let me know.