Wednesday, December 2, 2015

Thanks, Three Amigos!

One of my key learnings from my experience as SM if how hard the definition of a user story may become, as it requires an effective communication from the initial intent of the business staff to the final understanding by the DevTeam. A lot of literature can be found around this subject, but I want to share with you an experiment conducted with/by my team in the quest of the "nirvana" for the DoR.

The approach was derived from a fantastic idea by Ryan Thomas Hewitt, named Three Amigos; I guess you need no traslation to this... The idea is pretty simple, but effective: let's pair, if you allow me the expression, the Business Analyst with the Tester and the Developer. Starting from a proposal of description produced by the BA, they iterate to improve such description with a higher level of detail until they all have the same understanding and agree the story is ready for development.

In our own trial, that was sponsored by the guild or system team of Quality Enablement, our initial goal was to ensure a complete alignment between the Business Analyst and the Tester by assigning the first one the task of writing the test scenarios in the BDD format of Given/When/Then. But we took the trial to the extreme of asking the BA to use kind of Gherkin language and to operate a repositoy of scenarios, so that their definition was almost directly applicable to .feature files. Even a website application was built to assist the BAs in manipulating those .feature files, but in a guided environment and insulated from the complexity of purely technical tools such as eclipse.

Our experiment failed, but that was as good as it would have been, had it succeded. We learned a couple of things: you will hardly obtain productive outcomes in the technical side when you ask the business guys to do it.

The second learning was that we were missing the other crucial piece: the Developer. An agreement reached only between the BA and the Tester does not ensure the alignment of the developed feature with its acceptance criteria.

So, we changed our mind with respect to the tool, but also found a simpler way to the ThreeAmigos approach:

  • first, the BA defines the acceptance criteria, describing scenarios, events and outputs but in plain spanish
  • secondly, the BA joins the Tester and the Developer so that they navigate through the full set of requirements and reach a common understanding
  • third, the Tester defines the acceptance tests using Gherkin

I would say this approach is completely compatible with the idea of the 3Cs (card, conversation and confirmation), since all three actions are activated here, but it makes very clear the responsabilities of each role, and furthermore, the accountability of all of them as a team.

No comments :

Post a Comment