Last week, at New York Scrum User Group (NYSUG) monthly event, co-facilitated by the agile coaches Dana Pylayeva and Emilie Franchomme, there were multiple agile games presented – all for different purposes and for all types of audience. Above all, what really stood out was the “Beautiful Meadow” game that helped with making a revealing discovery about handling business requirements. Below is the summary:
Team A and Team B, of 8 people each, were given the following drawing instructions (click on the image below to enlarge):
|Team A||Team B|
The requirements of Team A were very detailed, whereas the requirements of Team B were rather generic. Each team was given a set of color markers and a large flip-chart sheet. Both teams were allowed to review the requirements in silence – for 30 seconds. Then both teams were given another 60 seconds to draw a picture, based on given requirements, but they were allowed to collaborate in sign language only.
Observations and Results:
For the first 30 seconds of the exercise both teams’ dynamics were very similar: hurdling around the requirement, trying to understand it, orienting yourselves are around the canvas. Silently, some people seemed to volunteer to draw various elements of the picture. For the second 60 seconds interval, dynamics significantly changed:
At a glance, Team A seemed to be somewhere less organized and more hectic. People seemed to move around the canvas anxiously, trying to pull markers from each other’s hand. What also became obvious was that each person was trying maximize their contribution to the picture, by drawing in a silo, without much collaboration with others.
Team B, on the other hand, seemed to be much more organized and focused. Individual work of each person seemed like a continuity of someone else’s effort. Markers were effectively passed on from one person to another. There was much more collaboration and common effort here.
After 60 seconds of drawing, the teams produced two images, illustrated below: Team A – left canvas, Team B -right canvas (click on the image below to enlarge):
Team A has produced a picture that consisted of multiple disjointed elements that together did not seem to fit well. Oddly it even produced two suns – in two opposite corners of the canvas, whereas the instructions clearly asked only for one sun.
On contrary, Team B was able to produce a simple, coherent logical picture, with each element enriching the overall composition with additional relevant detail.
This exercise clearly demonstrated that too detailed requirements, passed on to a group of individuals, as one conclusive document, are executed much poorer than light requirements passed on to a similar group of people. In case of Team B, there was a request of “WHAT” to draw, not “HOW”. The team was able to use all of this innovation and artistic skills to produce what was required. Oppositely, team A was asked to delivery “WHAT & HOW” and the teams’ ability improvise on-the-fly was significantly reduced.
There were two sets of teams (two Team A and two Team B) and the results produced by the second set of teams were very similar to the case described above.
Relevant Article: Waterfall Requirements in Agile Product Development
3 thoughts on “How Detailed Should Business Requirements Be? Discovery Through Agile Gaming.”
Thanks for the article, Gene!
I discovered that game at Agile Games France a few years ago, and this is still one of my favorites to play!
Thanks again to David Barnholdt who invented it and shared it here https://blog.crisp.se/2009/02/18/davidbarnholdt/1234986060000
Very interesting game. One question out of curiosity, had the Team A been more organized and had identified the roles clearly, would they have produced a better picture?
What I am trying to understand is that the bad outcome is due to detailed requirements or bad execution?
IMO, it could be a combination of both. But team A was not not composed on people that were distinctly more organized. Teaming was random.