Intro
Welcome to a very special part of my work 💜. If you are familiar with my background in Language Teaching —it doesn’t matter if you aren’t—, something I am familiar and love doing is eliciting information.
Eliciting —in Linguistics— refers to a set of techniques used to getting someone to provide or remember information rather than telling them the answer right away. It leverages and builds on their previous knowledge of the topic.
In Business, this applies to having stakeholders provide you information about their process, needs and expectations that will eventually contribute to the overall understanding of the ‘current’ and ‘future’ state of the project.
Typically the witch in charge of a process as complex as this is experienced not only understanding the technology involved, but analyzing the business’ procedures. This witch can recommend ideal solutions for performing a Discovery of what is currently implemented and what the goal of the enchantment is. How should you proceed? Keep reading 🪬
Context Comprehension
As daunting as it sounds, understanding the business’ current pain points and translating them to the soon-to-be enabled technology is the key to execute any project. The process involves actively listening to the client’s needs and requirements.
Once an initial discussion has been established, you have the necessary information to start planning the project Discovery.
A Discovery process involves the Product Owner, Implementation Team, and other business key stakeholders to scrutinize user needs, generate ideas, and corroborate hypotheses about the potential product features that will help ensure that whatever is being built will be valuable and useful. to the business/stakeholders.
Discovery Planning
Based on the answers and understanding the team has obtained from the initial conversation, and depending on the industry you are working with, you may need to leverage different approaches to elicit the right information from the right forum. This not only applies to the client, but to your team as well.
e.g. IT Team won’t be able to provide you insights on the campaign strategies the business wants to have enabled, but will definitely be the appropriate ones to explain how the Data Model and the overall architecture work.
If you are acquainted with the fine art of gathering information, are proficient in the system(s) to implement, and can perform the whole process by yourself —kudos fellow High Sorcerer! 💜. Nevertheless, if the reunion will be related to the business’ marketing strategy, bring an expert in marketing from your team as 2 heads will always be better than 1, and they may ask more questions that you didn’t initially think of.
There are an incredible number of methods to retrieve information, some more suitable than others depending on your objective:
- Will you educate the client on what is possible to execute?
- Perhaps explore ideas with their different sectors?
- Organize workshops for each business area?
- Are you looking to verify the requirements?
Prepare in advance your goals, materials, logistics, follow-up steps, and set up a precise agenda with the proper participants.
Be transparent and clearly communicate to stakeholders the expectations, roles and responsibilities they’ll undertake during the Discovery meetings.
Active Engagement [Discovery]
If you have prepared thoroughly, your elicitation phase (Discovery) will be a tremendous success! (or not, let’s be honest 🤷🏻♂️). This phase is where most of the time will be invested, so do it wisely to avoid reworking incantations.
First and foremost, eliciting information is not a one-way conversation, but a dialogue between your team and the business. Engage and actively listen to the stakeholders as they are the experts in their own needs.
Ask open questions, rephrase to confirm understanding in case there was any doubt, paraphrase and summarize the data you are obtaining from the client.
Identify any risks/conflicts from the dialogue you are carrying out, and as a best practice, to enhance your enchantment and protect the team, place all recognized hazards on the table and be absolutely transparent when communicating them. Based on all perspectives and interests, negotiate with stakeholders to have shared agreements that benefit all parties, assemble them and deliver the information to everyone involved to establish a common ground before casting any incantations in the project.
Don’t be discouraged if on your first attempt to gather information the spell doesn’t go as intended. There will typically be stones in the road, but take the time to reflect on what was learnt, and proceed accordingly adapting to the business’ objectives.
Refinement
Would you confidently say completing all of the above steps is sufficient to begin with the implementation? The answer will most likely be No, and it has nothing to do with your prior activities —stakeholders could have forgotten to mention something important, or more frequently, after reviewing the gathered information the team noticed they could explore more in-depth on a certain topic to fully comprehend the requirement to appropriately address the business’ need.
Right after each session review internally the main points of the call, the use case, stakeholder needs, risks, and next steps. Refine the principle ideas to ensure they are self-explanatory, consistent, all details are clear and that the team can properly test the spells before casting them into Production.
Does your team still have questions? It is completely normal to schedule a follow-up call letting the client know you would like to clarify and confirm all the insights gathered by the team. They can also validate the information to provide valuable feedback!
Document & Communicate
As a BA you do not need to know how everything is exactly enabled, but rather be acquainted on how systems integrate and work with each other. Scrutiny the requirements with the platform Developers to clarify on any technical questions to account for technical feasibility to guarantee what is requested to enable is realistically possible. You don’t want to have any surprise mid-spell-casting because the Technical Architect mentioned something is not possible to develop.
After all the implementation effort and information you now refined, it is time to document it in a fitting format to then share it to all parties and communicate findings. Leverage a wide range of techniques that are not exclusively text; provide visuals, presentations, self-explanatory artifacts that will reveal the feasibility of the project, and listen to the feedback to business may provide to determine a suitable set of actions to kick off with the spell-casting.
Most preferred methodology is Scrum (we still need to find the book with that scroll), which allows for suitably organizing the Discovery information and translate it to manageable fragments of data.i.e. You basically get a well-designed backlog of activities that will be performed in a short iteration, prioritizing needs depending on business’ requirements.
Bonus: The Scrum Methodology
Information on User Stories and Scrum can be found in the official Scrum website. Once we have found our spell book with the Scrum scroll we’ll let you know 🔮. In the meantime, it is only essential for you to understand what the main documentary capabilities of Scrum are and how you can leverage this approach to generate a functional backlog of items that will be prioritized by the client and that the sorcery team has to craft.
Scrum
Scrum is an agile framework used primarily in software development, but can extend to different fields. It promotes iterative progress, collaboration, and flexibility. Scrum helps teams work together to develop complex products while adapting to changing requirements. This framework utilizes several artifacts to manage the project workload:
Epics
Epics represent significant features or requirements. They are too big to be completed in a single Sprint and are often broken down into smaller fragments, User Stories. Epics help understand the broader context and high-level functionality of what is expected to develop.
User Stories
These are concise, simple descriptions of a feature from the perspective of the users who will benefit from the project (end users). They are typically written in the format:
"As a [user role], I want [objective] so that [reasoning]."
User Stories help the team understand user needs and prioritize work based on business value. They are small enough to be completed within a Sprint.
Sub/Tasks
Actionable items derived from user stories. They break down User Stories into specific, manageable activities that the development team can work on. Each task is assigned to a certain team member and has a clear, self-explanatory definition of what is supposed to be done.
Sprint
A Sprint is a determined period of time, having a consistent duration throughout the project usually lasting between 2 - 4 weeks, during which a specific set of work requires to be completed. Various ceremonies are scheduled to progress with the incantations:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Backlog
Finally, the Backlog, i.e. a comprehensive and prioritized list of work that needs to be done. These can also be enhancements, fixes, and/or new requirements for the product.
It is maintained by and expert Enchanter and is continuously refined.
To Sum-Up
The highlight for this spell is the importance of collaboration, adaptability, and stakeholder engagement throughout the Discovery process.
Utilize techniques such as user interviews, feedback sessions, and workshops to gather all necessary information for the project’s success, and when crafting deliverables/artifacts, consider requesting the business’ feedback to validate the data and confirm the defined agreements.
Ensure the requirements remain aligned with business’ goals and stakeholder expectations.
BE CURIOUS!