Posted by tac_admin, November 27, 2013

Elicitation Techniques in Agile

2013-10-25_0856The BABOK® Guide discusses BA elicitation techniques and methods of working with stakeholders to understand their concerns. When you elicit properly, you truly understand the stakeholders’ true needs, and the Agile Extension to the BABOK® Guide discusses these techniques in detail.

Elicitation is not a one-time activity, but continues through the project, beginning with an initial elicitation that looks at the project needs on a high level. Throughout the project, the elicitation becomes more detailed as the user stories and backlog become more refined. A myriad of techniques for elicitation, from preparation to result confirmation, are listed below.  

Elicitation Preparation:

    • Personas: Personas have specialized knowledge into the stakeholder’s specific needs and know which elicitation techniques may be most effective in understanding those needs.

  • User Stories: Used for the backlog, user stories identify stakeholders and their values, goals, and needs.

 

  • Story Mapping: A graphic representation of user stories, a story map keeps the team on track and gives them a tangible goal to aim for. The first story map is done by the BA, with assistance from stakeholders, to allocate resources and understand the requirements. The project will be guided by the backlog and its prioritization, which means later elicitation sessions will be tailored to the stakeholder.

 

Conducting of Elicitation:

  • Behavior Driven Development (BDD): It’s often easier for stakeholders to talk and give the team or the BA concrete examples of their needs (and behaviors surrounding those needs) instead of using abstract models.
  • Collaborative Games: To improve the accuracy of elicitation, collaborative games allow stakeholders and the team to build a joint understanding of a problem. After the high‐level requirements are noted, stakeholders work directly with the development team directly to ensure that the work fulfills the requirements and is performed correctly.

Documenting Elicitation Results:

  • Lightweight Documentation: Simply put, there is no separate documentation for elicitation and analysis because they occur simultaneously throughout the project. Agile minimizes time between the development of requirements and their implementation, so records of elicitation activities ensure that key decisions are understood later or that regulatory or legal requirements are met.

Confirming Elicitation Results:

  • Behavior Driven Development (BDD): Acceptance criteria that use examples rather than models confirm that the software meets requirements.
  • Retrospectives: Elicitation results are refuted or confirmed based on stakeholder feedback of live product testing or demonstration. Requirements may be changed, added, or deleted per the customer’s request.

Which elicitation techniques are your favorites?

 


5 responses to “Elicitation Techniques in Agile”

  1. Debbie M. says:

    You’ve given us lots of new ideas in this blog post. I hope that you will do a live webinar soon on the topic and maybe have us do some User Stories and Story Mapping on the call as a group. I am really enjoying the webinars and know they are very practical and valuable in the real world of work! Thanks.

  2. Pamela says:

    I will be engrossed in this blog during my travels today as you have provided a variety of ways to get and maintain the stakeholders engagement in an Agile like environment. They are using only the user stories and this blog emphasizes that are more to eliciting requirements in an Agile-like environment. I would like to see an example of the Story Mapping and a light documentation that would be required for a BA. Love this blog! Thanks for sharing.

  3. Amber says:

    At my company we are rethinking our elicitation process. We are modeling the business processes that exist on 98% of our projects and coming up with typical use cases that we can use as a framework to start conversations during our requirement workshops.

    We are found most clients prefer a BDD approach and looking for more prescriptive requirements from our side.

  4. Enn says:

    My favorite for conducintg elicitation is the Behavior Driven Development (BDD) because as a BA you have all the chance to speak and discuss with the stakeholders their actual needs. Showing the real scenario of the business, their problems and solutions are the best source of information if software actually meet its needs.

  5. Nutankumar says:

    First of all I like to say thank you for this blog ..came to know different elicitation techniques.

    In my company we have evolved in implementing the BA practices.
    The best elicitation technique I feel is to start with a checklist…. and go on a call.
    Checklist will be consisting bullet points which will be a part of your homework before going on a call.
    If we are expecting every bits and pieces from client than he might loose interest in you. So before going on a call we always have a basic idea about the project and depending upon it I Google few keywords and create bullet points and the Golden Set of questions which we always use on the call for e.g. 1. What is the problem we are trying to solve?
    2. How will we define and measure success? 3.How we will we define its actually “done?”
    Sometimes we need to do brainstorming in team before talking to client.

    Believe me this technique is quickest way to get the client on board.

Leave a Reply

Your email address will not be published. Required fields are marked *

Get in touch today

Speak directly with The Analyst Coach
and get pointed in the right direction.





Preferred Contact EmailPhone

Subscribe to receive our free white paper on how weak requirements effect strong companies




tesra-circleanalyst

Sign up to get your FREE Business Analyst Survival Guide

Don't worry, we hate spam too. We will never share your information to third parties.