A picture tells a thousand words. So prioritize pictures not words
Draw pictures to illustrate outcomes, design the user interface first and use that to prioritize requirements rather than working with written requirements.
In a single image you can convey a simple concept, an idea, a need or a desired outcome far quicker and more accurately than writing it in a sentence. This is especially so in developing software which more often than not is visually manifest as a user interface.
When we captured requirements in agile, we are effectively conveying a simple concept, idea, need or desired outcome as a requirement. And we do it in words. Those slippery things that are so often misunderstood. Things get really slippery when we try to prioritize those words against each other. Stories are laid out on the table and the team spend as much time discussing what each story actually means, as giving them priority. And because they are supposedly independent, you loose the inter-depedencies between them. Jeff Patton has written some great stuff on this.
So prioritization with stories can be flawed, especially when you are working with a large volume of requirements, say at the outset of a programme of work, and what you really want to do is get an idea of what a first release should be.
Throw out the stories. It’s too early to be writing words. Muda. Create illustrations of widgets and features and functions. Sketch out on post-its illustrations of the simplest implementation of the concept, idea, need or desire. On flip chart paper create blank screens that illustrate the interfaces that the requirement will be manifest on. Identify the stakeholders who will interact with the requirements. For example the retail website, the operational support application, the finance system. Now ask the team to stick onto the screens the sketches.
The challenge is to strip back to the minimal functionality that they really need for that first release. Let them draw extra functionality if they like, but everything must be on post-it notes. Now pull the post-it notes off, one by one. What if we removed this? What would happen if it wasn’t there? Is there something simpler we could do? Something more elegant? Is an operational function required to make the website function work? The exercise may be extended with pictures of legacy applications and data elements, again, stripping them back to the bare necessities for that first release.
That didn’t take long did it, and it looks like an initial release candidate. We’ve defined our scope in a way that we do not believe we can cut any more. Any less functionality would not be a meaningful release. Now we can get down to writing the stories, focusing our effort on something we are agreed looks right. We’ve prioritized pictures, outcomes over words; Picture Driven Design.