The group of villagers entered the forest, each hold a stake. Their aim was to hunt down the monster that was leeching the life blood from their community. These stakeholders sought to kill that which they did not understand.
Here are some approaches I’ve experienced over the years for figuring out what is needed to be done on a project.
Approach 1 The worst way to develop complex software is spent months building something no one really wants.
Approach 2 A more excellent way to develop software is to gather requirements for everyone that has a stake in the project.
Several years ago, I spent months creating a carefully documented set of requirements for a document management system. Our team of Java programmers were grateful, but I doubt they actually read my wonderful manifest of boring details. It was very dry. To make it worst, the document was “living” and and various parts would be updated periodically. Even with Microsoft Word’s “track changes”, reviewing the changes was difficult for anyone to fully wrap their minds around.
Approach 3 Another approach is to gather Use Cases. These are a few sentences that describe the steps a user takes to do something with the system. At first it seems like this approach would produce a more concise and useful document.
Unfortunately, for complex software, the end results can still be a long document that no one carefully reads or understands. I’ve also tried a hybrid approach of introducing sections of the document with use cases and then going into more detail with formal requirements. However, if the end result is more than seven pages, few on the team will really care. The rule Seven Plus or Minus Two is a good rule for any document that you want people to read.
Approach 4 User Stories are much more interesting than use cases. Instead of just a list of the steps, User Stories tap into the power of storytelling. It does require some creative writing skills, but this can be drawn out of the team as you pass it around for review. Each user should have a persona, or back story, that adds some depth to the story and gives the reader context for a deeper understanding. Through careful editing, you can pack an amazing amount of information into a few pages.
In addition to the formal “As a <role>, I want <goal/desire>” sentence structure, allowing additional sentence structures can keep the stories flowing and interesting.
The key to this approach is to move “requirements” is speed and frequency, not exhaustive (i.e. exhausting) documentation. As quickly as possible, get something working and in front of the stakeholders so they can react to it and get a better understanding of what they want, but didn’t know they wanted, until they saw something working.
Then, as quickly as possible (again), update the software with the things the stakeholders most want and show it to them again. Agility is much more important than including every feature all stakeholders want in the first release.
Approach 5 “Epic Stories” are stories that are very broad in scope and can include many user stories. They can used to structure the stories into a map for context.
Beyond just vague overviews, epic stories can be, well, epic. Truly epic stories are those stories that have high value to the user and expand the possibilities of what could be. After collecting a set of user stories, ask the question “how can this be more epic for the user?”.
Allow the stories to get out of the box, have some fun and give your team a vision of what might be amazing. Find something completely epic to do in the next Timebox and then go for it.
“Where there is no vision, the people perish” Proverbs 29:18A