Fifty percent of traditional software projects are delayed or goes beyond budget. Because of this, more and more organizations and exploring ways to deliver better software at the shortest possible time. Agile offers a strong alternative to the predictive or waterfall approach. According to the Agile Practice Guide,  Agile is “an approach to collaborative problem-solving for exploratory work informed by a mindset of values and principles as set forth in the Agile Manifesto”.

Business Analysts in the process of transitioning from a predictive to a more agile way of work can start incorporating various Agile tools and techniques to augment their requirements gathering process. This will enable a more collaborative and user-centered way of eliciting more important product features that welcomes and accepts the value of change.

Start with the Product Vision

The vision is a product’s overarching goal, describing its reason and desired end state. An effective vision can help clear expensive and time-consuming clutter of requirements gathering, making business analysts focus on the most important requirements that can bring the highest value.

A good product vision can also help align people, effectively coordinating actions not because they are obliged to, but because it motivates them. A shared sense of vision can help lessen constant conflict and endless meetings. With this, people can work with a certain degree of autonomy bringing in more creativity and productivity.

What makes a good Product Vision

How can business analysts then create an effective product vision? Well-renowned business change leader John Kotter says it must be aligned with these six characteristics:

• Imaginable and Desirable

The product vision must always be imaginable and desirable. It must perfectly convey how the future will look like not just for customers but also for other stakeholders such as employees and stockholders.

• Feasible and Focused

The product vision must also be feasible enough that it should be based on the organization’s current state, the market that it is in, together with other competitive trends. This will help in guiding the team make important decisions such as which features are important, and which are just “nice to haves”.

• Flexible and Communicable

When visions are challenged, it must also be flexible enough to accept change, making readjustments without having to lose its credibility. And finally, product visions must be simple enough so that it can be understood not just by the development team but also by many people.

Write about User Stories

One of the many reasons why agile requirements gathering is so effective, is that it shifts from writing about requirements to talking about them. Written in about a sentence or two, User Stories are product feature descriptions developed from the perspective of the people who will use it.

User Stories are very important because unlike writing requirements in isolation, business analysts can bring-in the end-users into the conversation early in the development process. This allows a greater sense of collaboration and participation, making it easier to identify, elaborate and prioritize the highest value adding features. User Stories follow a simple template:

As a (user/persona/customer), I want to (do something) so that I will (receive a benefit).

Details can be added in the user stories by splitting it into several smaller stories and by adding a condition of acceptance. Ron Jeffries also introduced the “three C approach” to give more depth in the development of User Stories. The “three C approach” refers to:

1. Card –Fill in all the blanks in the User Story template and put it in a card.
2. Conversation –Bring in more details about the User Story through having a conversation with the customer.
3. Confirmation –A User Acceptance criteria that tells the requirement is done, and the user is satisfied with the results. This is normally written at the back of a card.

Source: Solutions IQ

Bill Wake and Mark Cohn also recommended using the INVEST method to develop good user stories. INVEST refers to good stories as something that is Independent, Negotiable, Valuable, Estimable, Small and Testable.

Source: Michael Warden

Use MoSCoW and KANO Methods for Prioritization

When all requirements are deemed important by the customer, effective prioritization is vital to delivering the most value adding benefits of a software even early in the development cycle.

MoSCOW is an acronym for Must have, Should Have, Could Have and Won’t Have. It is an agile requirements prioritization technique Developed by Dai Clegg which is very useful in time-boxed development.

1. Must have– When requirements are labeled as a “must have”, they are critical to the current delivery time-box. Because of this, when a must-have item fails to be delivered, the whole increment will be declared a failure.
2. Should have– These are important requirements, but not mandatory in the current time-box. In effect, a should-have requirement can be moved to the next delivery date if development time is no longer enough.
3. Could have– Could have requirements are often desirable because they can improve user experience or satisfaction, but they are not necessary. They can be included if time and budget permits.
4. Won’t have– These requirements are often the least-critical features, and could be deferred in a later timebox.

Another useful agile requirement prioritization method is the KANO Model. Developed by Dr. Noriaki Kano in 1984, it can help in effective requirements prioritization by classifying features into four categories based on customer perception. These are Performance, Must-be, Attractive and Indifferent.

Source: Folding Burritos

To use the Kano method, create a questionnaire for each of your product features. Ideally, a wireframe can be used to effectively show a feature works, otherwise, a detailed description should suffice. Each question should ask the following:

1. If you had (feature), how do you feel?
2. If you didn’t have (feature), how do you feel?

Participant responses should range from:

1. I like it
2. I expect it
3. I’m neutral
4. I can tolerate it
5. I dislike it

A third question according to Jan Mooran can also be added: “How important is this feature?”. To answer, users will choose on a nine-point Liker scale ranging from “Extremely Important” to “Not at all Important”.

Conclusion

To have a more collaborative and user-centered way of requirement gathering that welcomes and accepts the value of change, business analysts must incorporate various agile tools and techniques. Remember, always start with a vision in mind. This overarching goal can help clear expensive and time-consuming clutter of requirements gathering. Second, frame the requirements in the form of a user story. Product feature descriptions written from the perspective of the people who will use it, makes requirements identification, elaboration and prioritization easier. Finally, adopt a more efficient requirements prioritization process by using either the MoSCoW or the KANO Method as this is vital to the delivery of the most value-adding features even early in the development cycle.