It all starts with a structured discovery !
I’m pretty sure confusion is the dominant sentiment when it comes to facilitating discovery of any Project and this emotion is aggravated further if you are new to the Business Analyst (BA) or Product Owner (PO) role. One usually starts off with whatever material they could scavenge on inceptions and discovery sessions from the internet, the second step is usually talking to experienced folks to know about few tips and tricks that can be used and the final step is still not knowing where to get started !!!
I recently facilitated inception of a project wherein the product vision was to deliver APIs as a product offering. It’s a common notion to think what a BA or a PO would contribute while discovering features and capabilities of APIs as a product. I’m pretty elated to confirm that this notion holds no ground and there’s a lot a BA or PO can drive and steer to obtain business oriented outcomes. At the end of the day, APIs are nothing but a tech behind doing a business operation. This simply means that we can not and should definitely not separate out business value from the API. Without a business need, API would make no sense, hence it’s pivotal to discuss the business context for API Products and that’s precisely where a BA or PO enters.
Since it’s established we can’t do without a BA or PO even when it comes to API Products, we need to understand how can these roles be more effective in making sure that discovery is successful. There definitely is no one-size-fits-all technique that would work for all the projects, but there sure are few suggestions that might help to have an outcome focussed and structured discovery. Let’s look at few of the recommendations !
Keep one-stop documentation for the entire discovery
Create a running document and use the document to facilitate sessions as well as to capture outcomes of each session. Maintaining the document around all the discussions and agreed decisions at one place helps the stakeholders and the team to refer to a single source of truth. In the latest discovery that my team did, we used a running live mural and segregated the mural into areas, where each pair of area was dedicated to a session and its outcome. At the end of the inception, we had a pretty detailed and comprehensive mural documentation which was deeply appreciated by the stakeholders as well since it gave them a view of the endowed progress of the discovery and was a key indicator of the success of the sessions.
Set the priorities right from the beginning
We usually tend to postpone the Prioritisation conversation to a later day and are inclined to skip those discussions during discovery. It’s important to understand the holistic picture during discovery but it’s all the more important to consider that something that has to be worked on a year later need not be discussed in detail then and there. We should look at discussing the most essential capabilities in depth instead of talking about the frills. Hence, a prioritisation session of capabilities during the beginning of the discovery would help to have focussed discussions in the follow up sessions as well. During the discovery of the API Product, we made sure to talk about Business Capabilities and Workflows that are to be exposed using the APIs and we explicitly had a Session for Prioritising the Business Workflows using MoSCoW techniques. This call helped us to align the tech focussed sessions to cover only the prioritised must have flows instead of beating the bush around the not-so-important user flows.
Don’t loose track of the tech sessions
It’s okay to not be okay but it’s not okay to let your brain go into sleep mode when a tech session is going on during discovery. It’s very human that it might be difficult to wrap our heads around every bit of architectural knitty-gritty but it’s not impossible to understand how things are happening on a high level and who says you can’t ask silly questions !? Once a BA or PO understands the how behind the what, it becomes easier to connect the dots between the functional stories and the tech tasks. It also becomes easier to create Tech Stories when you know why is it necessary and for what all functional tasks this tech story is a pre-requisite. It definitely becomes easier for the developers and quality analysts to talk in their own language with you because they would know that you are understanding. And of course there would be times when you pass through a convoluted tech task and you get absolutely nothing, but again who says you can’t ask silly questions !? Crux of the story is to remain attentive during the tech sessions so that you gain a semblance of the architecture which would undoubtedly help you while slicing and dicing the stories.
Assemble all the dependent teams
Most often that not, even when you build a new system you would have few dependent systems that would have to be coupled to the new system for exchanging data and information, be it through APIs or having common data sources or shared web UI components. It is of paramount importance to capture these dependencies upfront not just with the stakeholders but with the team leads and BAs of other Teams so that everyone understands the ownership boundaries to avoid last minute accountability confusions. During the discovery that our team conducted, we managed to gather all the tech leads of the teams that we might affect or might need help from during the course of our development and we categorically called out the support we required and responsibilities that the teams owned. It helped us to start off on the right note and the discussion was also instrumental in setting up context for the subsequent calls.
Don’t forget the CFRs
Never underestimate the power of what discussions around cross-functional requirements can bring to the table. There is a compelling need to understand which out of all the cross-functional requirements (CFRs) are the top priorities for the stakeholders and hence it requires to conduct dedicated sessions in the agenda to have CFRs’ Prioritisation done and thereby taking a deep dive into the chosen ones. This session aids the BA to bake the non-functional requirements into the functional stories to have a well rounded deliverable. We conducted a CFR session during the API product discovery and presented about 10 CFRs by shortlisting the ones that the team thought would be essentials for a quality product, out of this we asked the stakeholders to pick their top 5 unanimously. Finally, we had the top picks, few of them being Performance, Availability & Usability and we streamlined all the discussions to the above mentioned requirements. This exercise prepared us to avoid any future surprises that might have bloated the scope later on.
Add some Shazam
Discovery could be rather strenuous and tiring, there is an utmost need to add moments of joy and rejoice. Be generous with few digressions that can lighten up the mood in the room (or should I say Zoom/Teams call). Don’t jump right away to the agenda as soon as the meeting starts rather set up a good mood within the participants by talking about anything but work. Build some mystery around certain decisions (only those decisions that wouldn’t annoy the stakeholders). What’s the most important outcome out of a discovery ? Is it Master Story List or a Prioritised Backlog or an agreed Architecture ? No, it’s none of these. The most sought after closure from a discovery is to conclude on a Team Name. We were successful to make the Team Name revelation a big deal during the Discovery Showcase and we had started building up everyone’s curiosity from Day 1 of inception. We all had a great laugh when the Team Name was revealed. I’ll refrain from mentioning it here. Let’s just say, it’s cool !
Discovery is an interesting time for a BA or a PO, there is so much to learn, so much to take away, so many valuable feedbacks and such great interactions which makes all the effort just worthwhile. A discovery is successful not when the stakeholders are happy but when every team member involved thinks that they have grown through this experience. A solid discovery is a foundation of a solid team.
