Have you started a planned sprint only to realise hidden dependencies? Thought your stories were adequately analysed, and realised mid-sprint that they were not really sprint ready?
Relax, you are not alone!
It’s day one of a new sprint and something’s missing from a story being played. You need to swap it with another story from the backlog, but it hasn’t been analysed. The business analyst (BA) spends days grooming the story mid-sprint, all while dev work is ongoing – it feels a bit like changing a jet engine mid-flight.
Developers, testers and BAs can all have different perspectives of the same story, which can cause challenges. Note that BA’s act as testers when there isn’t a dedicated tester role in an organisation.
Picture this – the team is trying to estimate a story, but cannot agree and begins discussing the details, prolonging the session, which is meant to be an agreement of priorities.
These kinds of scenarios create confusion within the team and business. Developers and testers don’t get used consistently, ultimately causing delays. This puts a lot of pressure on the whole team. No one enjoys that much pressure.
The story isn’t understood by the whole scrum team because it’s missing critical information. The team collectively doesn’t feel confident as specifics and dependencies were not identified upfront.
The team isn’t ready to develop, the story isn’t sprint ready.
Now, wouldn’t it be awesome if the developers and testers could readily estimate a story without debate, or have a swift sprint planning session, where developers breeze through development, testers have all the use cases clearly articulated and fly through the testing without any issues? This isn't a dream; scrum teams consistently make this a reality.
If I could explain agile in one word, it would be feedback.
Most people get the concept of agile when they say it emphasises engaging stakeholders early on. Developers and testers are crucial stakeholders too, why not engage them early on? Why startle them with a story on the planning day? Why not give them plenty of time to research, absorb, critique, debate, and develop a shared comfort with stories? This is why we introduced....
The Three Amigos a.k.a. story time or story kick off, is a meeting that doesn’t actually involve watching a movie with Steve Martin, Chevy Chase or Martin Short. It’s a meeting with developer and tester, where the BA introduces a user story for the first time.
The purpose is to familiarise the team with a story and help develop a common understanding.
The trio goes through the acceptance criteria and test scenarios together in detail with different perspectives in mind.
Traditionally a business analyst, at least one developer and tester attend this meeting. Depending on the feature that’s being discussed, product owner, architect or any other team member may get involved. Remember, BA’s act as testers when there isn’t a dedicated tester role in your organisation.
This is usually conducted a sprint before the story is expected to be picked up. This allows the team sufficient time to think about the upcoming story, ask questions, do some research, and request for follow-up Three Amigo sessions if needed.
Keep it short and simple, typically no more than 30 minutes depending on the feature. Remember, agile is all about feedback and being, well, agile. If you can’t discuss it in 30 minutes, break it up.
The Three Amigos can get mixed up with backlog refinement, however backlog refinement is very different. Backlog refinement is for the product owner to prioritise the backlog based on any new changes that may have occurred in the current sprint, bring forward any dependencies and ensure that entire team is aware of what is coming next. The whole team attends the backlog refinement and it is scheduled on a regular basis.
Using the Three Amigos will:
The Three Amigos should be conducted as often as needed, and used with a small group to be effective.
Keep in mind any “gotchas” in the story during the Three Amigos such as new technologies to be used, any experimentation required for designing the solution, prototypes, test rigs, wireframes, architectural decisions and approvals required.
Don't forget the most important lesson of all - Be confident, have fun and have successful sprint after sprint.
Savitha Krishnamurthy is a Senior Technical Business Analyst at Versent. She is a passionate consultant with an unshakable focus on the success of business partners. An avid problem solver who leverages technology to hit high value business goals; on time, every time. When she isn't solving problems at work, Sav enjoys art and craft with her two kids as well as baking.
Thank you! Your submission has been received!
Apologies, something went wrong while submitting the form. Please try again.