How Detailed Should Business Requirements Be? Discovery Through Agile Gaming.

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:

Game Rules:

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 glace, 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

What Should Agile Leadership Care About?

Agile frameworks (e.g. Scrum, Kanban, XP), individuals’ roles & responsibilities, processes & tools, metrics & reporting, burn-up charts, estimation techniques, backlog prioritization, agile engineering practices, agile maturity models etc. – all of them are important attributes of a typical agile transformation.  However, NONE of them are first-degree-of-importance system variables that are responsible for transformation success.  Most of them, are good superficial lagging indicators of agility but they are all corollary (secondary and tertiary) to another much more important system variable.

What is the most important system variable that defines a company’s agility?  It is Organizational Design –  the most deeply rooted element of organizational ecosystem that defines most of system dynamics.

When organizational leadership decides to take an organization through an agile transformation journey (it could take years, sometimes), it [leadership] needs to acknowledge that real, sustainable agile changes are only possible if deep, systemic organizational improvements are being made.  For that, leadership needs to be prepared to provide to its organization much more than just support in spirit, accompanied organizational messages of encouragement and statements of vision.  Leadership must be prepared to intimately engage with the rest of an organization, by doing a lot of real “gemba” (genchi genbutsu (現地現物)) and change/challenge things that for decades, and sometimes for centuries, have been treated as de-facto.

What does it really mean for leadership to engage at System Level?  First, it is important to identify what a system is: what are a system’s outer boundaries?  For example, one of the most commonly seen mistakes that companies make when they decide on “scope of agile transformation” is limiting its efforts to a stand-alone organizational vertical, e.g. Technology – and just focusing there.  Although this could bring a lot of local (to IT) success, it may also create unforeseen and undesirable friction between the part of an organization that has decided to change (IT) and the part of an organization that decided to remain ‘as is’ (e.g. Operations, Marketing).  For example, if Scrum teams successfully adopt CI/CD, TDD or other effective engineering practices that enable them deliver PSPI at the end of every sprint, but business is not able to keep up with consumption of deliverables (too many approvals, sign offs, red tape) then the whole purpose of delivering early and often gets defeated.  Then, instead of delivering to customers soon, in exchange for timely feedback, teams end up delivering in large batches and too far apart on a time scale.

A successful Agile Leader must treat an organization, that is expected to transform, as a sushi roll.  Just like seaweed alone does not provide a full spectrum of flavors and does not represent a complete, healthy meal, one single department (e.g. IT) is not sufficient enough to participate in agile transformation efforts.  Other organizational layers need to be included as well, when identifying a slice for agile transformation experiment.  A slice does not have be too thick. In fact, if organizational slice is too thick, it might be too big to “swallow and digest”.  But still, even when sliced thinly, an organization must include enough layers, to be considered as a ‘complete meal’.

Note: A great example of treating an organization as a sushi role, while making it more agile, is Large Scale Scrum (LeSS) adoption.

So, what are some key focus areas that every Agile Leader must keep in mind, while setting an organization on agile transformation course?

  • Location strategies. Geographic locations.
  • HR policies (e.g. career growth opportunities, compensation, promotions)
  • Budgeting & Finance
  • Intra-departmental internal boundaries and spheres of influence
  • Organizational Leadership Style
  • And some other areas that historically have been considered as …untouchable

All the above listed areas are defined by Organizational Design and can be better understood through self-assessment, done by organizational leaders at all levels.

Diagnosing Challenges in Scrum

When people go to the doctor’s office, they often complain of superficial manifestations of a problem (i.e., “chief complaints”) that don’t present any serious concerns, but in reality, are indicators of a much more serious systemic illness.

I’ve come to the conclusion that we in the Scrum field are also dealing with a similar type of scenario.

For those of us who have been coaching for a while, it’s probably a common experience to have a team member or a manager come to us with what appears to them as a “key problem,” but in reality, turns out to be a symptom of a much more serious underlying dysfunction.

On June 1, 2015…(read more from the original post)