Archive for July 2007
Scenarios are proving out to be a necessity as the complexity and scope of the solution keeps growing to handle the 21st century global businesses. It ensures that the functionality needed in the solution doesn't remain hidden or unidentified. Stories can then be stem out of these scenarios. The other way round, stories can always be traced back to the scenarios. Overall, there's a better management of stories; missing ones can be identified and added soon, and the duplicates can be identified and eliminated as easily. There's yet another soft benefit to it. The teams can be divided to work on scenarios rather than disparate and unrelated pieces of functionality. For the product owners it becomes easier to see the big picture and priorotize functionality. Scenarios also make the release features easy to decide. So, as an example, with scenarios identified the product owners can decide that as part of release 1 the users would be able to generate and print but won't be able to convert documents into different formats like PDF, etc.
- Often, people in the room forget to take the opinion of folks on the phone,
- Not being physically present in the room takes away the advantage of having a big picture in front of you, and
- If there are changes being made to the index cards on the wall, it is hard to catch the subtle differences between the original and the new text.
- No cards decks are required
- No wall space, except for projector screen is required
- Remote participants, who usually don't see physical card walls, can see all the cards which enhances their experience and contribution
One of the most important aspects of any project, especially one involving a computer software / system is defining a set of accurate requirements. But many a times people end up either with too many requirements or too little. Sometimes you get requirements that seem necessary at first only to end up as superfluous or non-necessary for the scope of the project. There is this constant fear in the minds of the Business Analyst and Project Manager that somehow, somewhere, sometime along the due diligence and the long drawn out process of requirements elicitation, they have overlooked or completely missed a few critical requirements or what they say “must haves” and instead have included or focused on the ones that would have been the “nice to haves”. The result of “missed” requirements could potentially be catastrophic. If discovered way down during the development life cycle, these missed must haves can be quite costly in terms of time and labor to be added to the scope of the project. Similarly the erroneously included nice to haves can drag the project schedule beyond the already tight timelines and deadlines.
So the question is, how does a Business Analyst efficiently and effectively determine the absolutely necessary set of valid, complete and accurate requirements? And more importantly what do we refer to such a set of requirements? Over the years, I have come to use the term “beautiful” to such requirements. Yes, beautiful. Well that’s what everyone involved in the project is looking for isn’t it? Nobody wants “all” the requirements, nobody wants “valid” requirements, nobody wants “complete” requirements, and nobody wants “minimum” requirements. Everybody wants “beautiful” requirements.
The task to compile a list of “beautiful” or “wonderful” requirements can be gargantuan. There is no universal way. There is no magic pill. There is no silver bullet. Each complex project requires its own ministration. The BA must wear multiple hats and take on different responsibilities from being the business analyst to being the project manager to the user interface specialist to the developers’ liaison to project champion to subject matter expert to cheerleader to cattle herder to everybody’s friend and simultaneously their worst nightmare. All the standard concepts and techniques of requirements elicitation and requirements refining will only leave you with a set of necessary requirements. That is Science. Converting them into Beautiful requirement is an Art. Especially when you are dealing with a multimillion dollar project spanning twenty something departments and affecting five hundred something stakeholders with hundreds of teams working on something or the other affecting your project and under aggressive time lines.
Is there a Ferrari waiting for me on this speedway of Requirements Analysis to take me from the Essential to the Beautiful requirements? Maybe. But the clock’s ticking. And I better get going.