Test Driving the Requirements Discovery Canvas

The Requirements Discovery Canvas is a visual tool that helps teams discover and organise software requirements. Inspired by the Business Model Canvas, it provides a framework for collaboration, that can be used by both agile and traditional software development teams. Its been over a year since I first published my “Requirements Discovery Canvas”.  Since then, I have learnt a lot from applying the canvas and sharing it with various groups in Australia and Asia.

When I read the words “Requirements Discovery Canvas” now, I find my emphasis has shifted away from “canvas” and towards “discovery”.

Canvases are great tools for externalising thinking.  They provide a framework for collaboration and a template for organising ideas as they emerge.  There seems to be have been a canvas explosion in the past year as more and more people discover these strengths.

But over the past year I have slowly realised that the greatest strength of a canvas is the way it provides a focus for “shared discovery”.  For many of the groups I have worked with, the canvas seems to provide a much needed challenge to their ideas about productive work.

I have found that many groups seem to believe that “real” work is a solitary activity. Staff should work quietly in their cubicles producing endless documents  that communicate their personal understanding to everyone else.  Unless of course another unproductive meeting gets in the way!

I find some groups take a lot of encouragement to stand up and work as a team using the canvas as a focal point for shared discovery. Each time we move on to a new section of the canvas, everyone tends to pick up a pen to write down their personal understanding of the task I have set them. 

I am surprised how often I need to remind them that if they continue down this path, they will waste a lot of “meeting” time reconciling everyone’s personal understanding before they can start to develop a shared understanding.  Sometimes they respond by telling me that they need to develop a rough draft of their ideas before capturing them in a perfect form on the canvas.  I have to remind them that this is not an exam and that understanding tends to thrive on the “roughness” of raw ideas.

I understand that spontaneously writing ideas on colourful sticky pads and organising them on a wall does not seem like very productive work to those from more conservative organisations and many worry about what the boss will think and the lack of “documentation”.

It is then that I introduce them to the concept of a “bus factor”.  How many of your team could get knocked down by a bus before the team would lose some essential knowledge?  Most teams are surprised when they realise that their “bus factor” is everyone in the team except the last person left standing!

Then I like to follow up by asking them if they have ever encountered documentation that is difficult to understand, out of date, incomplete or just plain wrong.  Many agree that I have just described the normal situation at their workplace.

I then take great pains to point out that documentation should not be confused with detail.  In the same way that story cards serve as place holders or reminders to have detailed conversations, the canvas provides a reminder to investigate detail based on shared understanding. Of course the ideas represented by the sticky notes will need elaboration!  This can be achieved in the same way as for story cards by talking to stakeholders at the most appropriate time; by capturing the detail in collaborative tools such as Trello or Jira or even by developing a traditional specification but one that is based on shared rather than personal understanding.