Once you've completed running your discovery workshops, interviews, show-and-tell, and other sessions, it's time to actually analyze all the findings and insights and produce the outcomes. Unfortunately, oftentimes this stage is overlooked, leading to issues with further project delivery. In this article, we will talk about typical artifacts that business analysts produce at the end of the requirements discovery, as well as how to actually transition these artifacts to the project delivery team.
Photo by Ketut Subiyanto from Pexels
Usually, the Analysis & Transition phase is when we begin preparing for the actual build, or delivery phase. Consequently, this is when you start seeing more and more people joining the team who are new to the business problem we're solving. As a BA or a consultant, your job is to help your new teammates get up to speed as quickly and seamlessly as possible to ensure the team is set up for success. Let's dive right in and find out how to properly finalize requirements discovery for IT business analysts.
A Guide to the Transition Meeting
I usually recommend handling the transition in a series of knowledge transfer sessions where you invite your new teammates - software developers, QA engineers, new BAs, and project managers - and present your discovery findings and all the outcome documents you've produced. This is where we actually show and walk the team through the actual feature backlog that we've collected, the solution design that we came up with, user experience wireframes, and UI designs, among others.
I want to emphasize that we don't just send the documents over the fence, hoping and assuming that people will read and understand everything right away. Things that are clear to you are most likely not clear to others, simply because they are new to the team and don't know the entire history and context of the business problem.
That's why it's crucial to provide the team with the right context - the history of discovery, how it all started, why your company was invited to participate, and who the people on the client side are that you have met. Are they IT folks or business folks? These details really help establish the proper context and are instrumental in helping your teammates get up to speed.
There are other standard topics that I recommend including in the transition session or sessions: a brief problem statement, the current solution that the client has, related pain points (whether business or IT-related), the expected timeline, projected launch date, and overall success criteria that we and the client have set for this project.
Artifacts Created at the Discovery Completion
Now let's talk about what specific artifacts we need to produce as the outcomes of our Discovery engagement.
UX/UI Artifacts
Let's begin with UX/UI artifacts - wireframes, user journeys, and personas. While there are numerous other UX/UI deliverables, we will focus on these commonly used ones.
Wireframes
Wireframes are low-fidelity visual prototypes that serve multiple purposes. They combine functional requirements, data elements, and specific functions on a single page in a manner that is easy and natural for end-users to comprehend and evaluate. A picture is worth a thousand words - this holds true for wireframes. It's important to note that wireframes are not typically referred to as visual designs because visual designs are usually prepared at a later stage in the process. However, wireframes are typically the starting point. The goal of wireframes is to present a coherent representation of what the end-user will see (such as a product detail page or news articles), what data and functions will be available (such as checkout, initiating a return order, viewing order history), and essentially how the user experience will appear and feel at each step of the user journey.
User Journeys
Moving on to user journeys, they are another valuable outcome to seek in the discovery process. A user journey illustrates the steps, actions, and interactions that users experience throughout their buying journey, registration process, returning a product, and so on. It is an effective tool for summarizing and communicating a high-level overview of the intended functionality, data points, and interactions. When coupled with wireframes, user journeys provide a powerful means of communicating the scope and functional requirements even before a single user story is written.
Personas
In certain discovery engagements, design and marketing teams also create personas. These personas are fictional characters that represent real-world end-users of your product, typically buyers or internal users like merchandisers or inventory managers. When used effectively, personas can uncover insights and customer needs that may not be immediately apparent. For example, if your website targets specific demographics, it may suggest the need for website translation into different languages. This, in turn, leads to the development of specific functional requirements related to translation and localization workflows.
Backlog
Another group of discovery artifacts lies within the functional area. These include features, epics, high-level user stories, and so on, collectively referred to as the Backlog. In the modern Agile environment, it is common for companies to capture high-level features in the Backlog, which are sufficient for estimating development efforts during the build phase. At this stage, it is not necessary to elaborate on all the acceptance criteria to determine whether it's a small or medium feature or assign it a point value of 5 to 8. Often, a high-level description of a feature, along with assumptions covering unknowns, dependencies, and constraints, is adequate at this level.
Use to Detect Change Requests
One important aspect to note is that you will likely use this backlog in the future when deciding whether a requirement that arises much later in the process should be considered a Change Request or not. For instance, during Sprint 4, a customer may ask when the Wishlist functionality will be ready. If it was not initially included in the Backlog, you have a legitimate reason to treat the Wishlist as a change request and request additional funding or adjust the scope by removing another feature to accommodate it.
In my opinion, the Backlog is the most important artifact produced as an outcome of the Discovery phase, and it will be utilized throughout the entire project. It is common practice to group features by areas or epics, assign them numbers for future reference, prioritize them as must-haves or nice-to-haves, and indicate their complexity or size.
Toolset
Regarding the toolset, I recommend starting with a spreadsheet because it is easy and convenient for the business to access, review, and provide feedback. Later, you can transfer it to your preferred tool such as Jira, Azure DevOps, or others.
Formal Approval of the Backlog
Once you have compiled the backlog, ensure that you have a formal approval procedure in place, especially for engagements with a fixed price or budget cap. It is essential to note that this approval does not contradict the nature of Agile or Scrum. We are not necessarily fixing the scope, but rather setting a baseline and early expectations regarding what will be built. As we progress in our Scrum process, we will define and prepare individual smaller user stories. However, these stories need to be traced or linked to the features from the backlog. This ensures that everything we build aligns with the approved backlog, minimizing any misunderstandings with the client in the future and allowing us to manage scope and change requests effectively.
Other Artifacts
Besides all, we also expect that at the end of the Discovery, we have a project plan with the projected launch date. We understand how we want to run our project and which methodology we want to use. We have identified the key team players, and the staffing plan is in place. Basically speaking, the artifacts we produce should be good enough to kick off the development and guide us through the implementation of the project.
What's Next?
The last question we need to answer is: What happens with the discovery team after the transition phase? Do they stay on the project team, or do they move on to handle another presale or discovery?
Well, it largely depends on your company and the nature of your business, but the general recommendation for consulting firms is to retain the discovery team for at least 3 to 4 development sprints. This approach serves a few purposes:
Firstly, it ensures that there are team members who possess a deep understanding of the customer's business context and can address many questions without necessarily reaching out to the client.
Secondly, it sends a positive message to the client that you are committed to their project's success and that your employees are dedicated to its completion.
Of course, in many cases, not all members of the discovery team can stay for the entire duration of the delivery phase. However, as a general recommendation, it is advisable to keep them on the project team, at least in the initial stages, for 3 to 4 sprints to facilitate a smooth transition.
Learn More
Interested in learning more? Check out my Discovery crash course on Udemy, where I teach business analysts and product owners all the fundamentals of requirements discovery: typical stages, team structure, meeting types, outcomes, and common mistakes, all within less than one hour!
Comentarios