Writing Agile Requirements

Lots of people believe that in agile environment, requirements are not necessary, that is not true at least according to me.

The requirements in agile environment are represented as user stories, user stories helps the team to understand who the actual users are, what they want, what is to be developed and what should it look like when it is completed. The ability to write and understand user stories is the heart of agile development and everyone involve in this environment which includes developers, BA, testers and business users should have or learn this skill.

When writing an agile requirement try to answer the following questions “Who, Why, What and When”. Start with gathering high level user stories to describe the needs and goals of the stakeholders, this will help you to identify project goals and deliverables. Every user story created there onwards should one way or another add value to the high level user stories, the advantage of that process is that if you find any stories which do not contribute to the high level goal you should ask ‘Do we really need this?” or perhaps you have misinterpreted/misunderstood the user story.

For each user stories it is also very important to write the acceptance criteria which usually come from business users. This is very crucial during the QA and UAT phase, do not leave this for later, it is very important and the best time to do this is when user stories are created.

During gathering agile requirement focus more on ‘why’ and ‘what’, do not fall into the trap of ‘how’ which is very tempting especially if you have developers and architect in the meetings.

For each requirement define the scenario broken down by pre-condition, actions and expected behaviours.

All the user stories collected during various meetings will form your product backlog, later based on the prioritisation user stories will be added to the iteration backlog.

The biggest advantage of agile requirements is when you have product managers, business users and developers working together you get the best outcome in the shortest period of time.

Finally don’t be tempted to gather and define all the user stories in advance, all you need is the user stories for the current release, once you get to a stage of implementing a user story that is when more details are needed.

Feel free to contact me if you have any questions, good luck with requirements gathering.

BA involvement in pre-sale support

As a BA you may be called upon to help the sales team with pre-sales support sometimes also called as Request for Proposal (RFP), although it is hard to generalise the content of the document they usually follow a standard format.

Sales people may not have the technical knowledge for the RPF and that is where the BA can be very handy, you may ask a question as to why not involve the technical people? The answer is very simple, most of the RFP are targeted to middle or senior manager and some may have the technical expertise but in my experience most don’t, so there is a need to represent the technical information in a business language.

BA will play a major role in designing and developing a prototype for the proposal, a good BA will spend reasonable time investigating customer’s business, trend and preferences to customize the demonstration that will make the customer more confident on your product/service.

Sales people are often stereotyped as commission hungry and income driven individuals , getting a BA involved in the sale gives customer the confident that your company is serious about the product/service and they are thinking of all the aspect of the sale like installation, implementation, training, support and maintenance.

There is one more advantage in this process, as a BA you experience firsthand the needs of a new customer this can be very handy to enhance the product and may lead to identify new opportunities and business sector.

Requirements Process - Three C Phase

Capture
Make sure you gather and capture as much requirements as possible, do not get too much worried about the format of the document or the structure, the focus should be more on completeness rather than tidiness or presentation. Involve the end-users or customers as much as possible during this phase. Make sure you record all the spoken and unspoken requirements, try to focus on what rather than how.

Clarify
In this phase make sure you clarify the requirement with the SME or users, developing prototype or test cases can help you clarify the requirements, make sure that the requirements are measurable, this phase is very important as it also determined the completeness of the requirement by formally inspecting the documents as a group.

Confirm
In this phase evaluate and agree which requirements will be done first, this phase will help you to remove those high cost but low value features. In this phase project scope will be identified and milestones will be defined.