From Stories to Scenarios - A necessary Step Back

The mindset, when it comes to software development, implementation, and rollout has changed a lot in the last few years. The early years were all about planning, designing, replanning and redesigning, developing, implementing and rollout. This age is all about doing precisely the same things as above, but in much smaller and frequent intervals. That's the difference between Waterfall and Agile sofware development mindset. Agility, however, demands a change in the size of each individual problem that is to be solved. In other words, problem is broken down into smaller chunks of work that are then tackled in a fixed but small interval of time, called iterations. So, instead of tackling the huge problem, we now deal with features that are right sized for an iteration, which can be a week, two week, or three weeks long - called "stories". Stories Stories became the way to implement functionality in Agile environments. It still is and probably will continue to be the way for another few years until something new and better come across. This is because it is manageable, concise, and yet valuable. However, in a large problem space, the identification of stories still remains an art. There is no science behind story identification. And, as is true with any art, only a few are masters at it. For the rest, it's still a nightmare when someone asks, "Are there any stories missing?", or, "Have you been able to identify all the stories?", or worse yet, "Based on the stories that you have identified, how long do you think it'll take us to build a fully functional software to market?". Questions like these have forced the agile practioners (analysts) to reconsider the way they view the problem space. While they realize that stories are the way to build sofware, one piece at a time, it is probably not the right level of granularity to begin with. That ought to be the scenarios. Scenarios We should not jump straight into breaking the big problem into stories directly. There's an intermediate step, called the scenarios. What all would an ideal and super user of the software would want to do, in his/her typical day? The answer to that, usually, is a collection of scenarios. So, if the problem space is to build a end-to-end front-end equipment leasing system, a scenario in there could be: "User generates and prints lease documents". "User converts lease documents to different industry standard formats".

Benefits

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.

Collaboration Unleashed - Cardmeeting, Planning Poker, and Skype

Collaboration has never been as important as it is now in the day and age of distributed projects. There is an ever increasing need for tools that simulate physical working environments with as much fidelity as possible. Simplicity is yet another attribute that is highly desired. No matter how innovative a tool is, if it's not simple to understand and easy to use, it's chances of a wide user base and retention go down drastically. In the last few months I have been introduced to tools and techniques that, I think, are unique in their simplicity and ease of use. Card Meeting As teams working in agile environments, one of the practices that is followed very religiously and by all members of the team is Retrospectives. The practice is self-explanatory - in short, it's a look back at the last iteration of work and an analysis of what went well, what didn't go so well, and what we can do to improve the situation. This is, typically, done in large meeting rooms with lots of wall space to stick up index card and stickies. As expected, it is a heavily communication oriented process that involves a lot of visual elements. Also, as expected, there are always team members that are working remote and are not physically present in the room. It has been my experience that for such people the effectiveness of a retrospective go down significantly for very many reasons. Some of them are:

1. Often, people in the room forget to take the opinion of folks on the phone,
2. Not being physically present in the room takes away the advantage of having a big picture in front of you, and
3. 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.

Card Meeting (www.cardmeeting.com), it seems is a solution to the problem. It is a very powerful, yet simple to use, online tool for recreating a card wall that we typically use for retrospectives. Very much like with paper cards, card meeting presents its participants with the freedome to create their own multi-color cards on which all of them write and vote. Some of the benefits are:

• 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

Skype (Groups) Another problem that I have faced in the past on large teams is daily communication. The communication that I am talking about is the chatter that we all are almost always interested in being on top of. Email in the past has been used for it but has proven to be in-effective. One of the team members on my last project came up with the idea to create groups of users on Skype. On that project there were 3-4 different groups, Business Analysts, Developers Team-A, Developers Team-B, etc. This provides users the capability to broadcast messages that aren't too important for an email and are very temporal. It also prevents the rest of the team from being disturbed by what they consider to be noise for them. Planning Poker Although I have, officially, never been a part of estimation process, I have sat through the sessions and have helped the process by giving whatever information was sought from me. One of the observations I made was that often the estimates were either revised by the estimator because they didn't have the full and clear picture of the functionality the first time or because they got influenced by the other estimators in the room. The former happens a lot when the estimators are working remote and the latter when the estimators are all in one room and can see each other. Planning Poker (http://www.planningpoker.com/) is an online estimation tool on which you can upload a list of stories using an Excel sheet that are then presented to its participants one at a time. The participants, which usually are also on a conference call discuss each story and post their estimates that are not revealed to the group until the last participant has voted. At the time, all the votes are revealed. This can be any number of times until the group has reached a consensus. Summary In the recent few months, each of these tools; Card Meeting, Planning Poker, and Skype Groups have proven very effective for me on distributed projects both individually and collectively. They have enabled teams to work more effectively and efficiently and most of all, I have seen little or no resistance to their acceptance.

From Necessity to Nefertiti

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.