Whether you are an enterprise or a startup it is crucial that you and your team include an Agile
Requirement discovery phase at the beginning in your process. Commonly known as Agile
Requirements Envisioning or Product Kickoff the Discovery phase allows the Stakeholders to come
together and create a shared understanding of the overall product or project goals.
If done right Agile Requirements Discovery can help the team mitigate
the risks associated with Miscommunication and Misunderstanding of product requirements.
By incorporating feedback early on your team creates a collaborative Vision,
a North Star which ensures that each step your team takes during the product
development leads to the same end goal and business benefits that everyone hoped for.
Hey Friends welcome back to the channel. If you're new here my name is Vibhor. I am an
Agile Leadership and Transformation Coach based in Toronto Canada and on this channel, we explore
the strategies tools and tutorials that help us become more productive as Scrum Masters and Agile
Coaches. In this video we are going to be talking about five best practices for Agile Requirements
Discovery that I used as an Agile Coach to help my product teams get started on the right foot.
Have you ever been on a project or product development effort and it just didn't feel like
everyone was moving in the same direction or there wasn't a lot of alignment? You didn't understand
why you were building what you were building or people were arguing that this feature is
more important than that feature and worse yet when the final product comes out the
response that you get from the customer is, "hmm that's not exactly what we intended."
Well say hello to Agile Requirements Discovery which helps us understand the business benefits,
quantify the product goals and share a common Vision statement
making sure that we are all on the same page and in alignment. Unlike traditional waterfall
environment where Requirements Discovery happens at the very beginning and the beginning only
in Agile the Requirements Discovery is integrated as part of the process and happens throughout the
life cycle of the product. A shameless plug I am planning to create a tutorial series where
I will discuss in detail about how to actually go about doing product discovery using impact
maps which leads to product Vision, which leads to product road maps and finally the
release plan. All right with that out of the way here are five best practices to make sure
Agile requirements discovery is a success. Using the right amount of upfront planning
and design. This is clearly the most important practice to use in Agile Requirements Discovery.
Now it is not advisable to start with a blank sheet of paper nor is it a good idea to go
overboard and plan every single detail upfront. Agile prefers a midway and this middle way depends
upon a number of factors including the level of uncertainty and complexity in a project.
So how do we do this and find this middle way. Here are a few suggestions you can try. Avoid
Speculation. That's right, try not to make decisions based on assumptions. Unless it is
absolutely unavoidable differ assumption-based decisions as much as you can. This brings us to
the next suggestion which is make use of the last responsible moment. Last Responsible Moment refers
to the strategy of not making premature decisions but instead delaying commitment, keeping important
and irreversible decisions open until the cost of not making decision becomes greater than the cost
of making a decision. With that said the third suggestion is, not to try to reinvent the wheel.
There is no value in ignoring the historical data that you already have available.
We should use what has already been discovered but at the same time try not to make wild assumptions.
For example, if you are given a task to create an electric car would you just go out and start
making one from scratch? There is a plethora of research available and it would be foolish
not to use that research in our efforts. All right time for the next best practice. Regular
participation by stakeholders. Now I get it Agile Product Owner plays an important role
and holds the accountability for the overall success and failure of the project from the
business point of view which makes the Product Owner the key decision maker for product or
project requirements. This makes people and particularly members of the team assume
that Product Owner is the only person they should talk to or are allowed to talk to
which definitely is not the case. This might work really well in small project setting,
however when it comes to huge complex products or projects, the communication funnel created by the
Product Owner may act as a bottleneck slowing the whole team down. For these reasons Stakeholders
should actively participate in discovery sessions so team can ask clarifying questions and listen to
the answers directly from the horse's mouth and repeat asking questions if things are not clear.
This back and forth Q & A provides the team valuable insight into stakeholders needs.
Keep in mind that the team should never bypass the Product Owner and all the Stakeholder discussions
must be done keeping the Product Owner in loop. In fact I suggest that Product Owners must facilitate
these sessions for the best outcome. Next finish the cake bite by bite. If we think
of the overall vision of the product as a huge cake then the team should focus on finishing the
cake one bite at a time. Thinking of gobbling the whole cake in one go is not a good idea.
Working on short-term milestones or MVPs will not only help in demonstrating quick progress
but also the chunks of value returned as quickly as possible. Needs and Wants. Now at first glance
the difference between wants and needs might seem obvious. Wants are the things that you want to
have needs are the things that you need to have. But it's not as simple as that. Think about going
to an airport. Now buying duty-free chocolates and champagne, although very attractive,
and I mean very attractive, is still a want, which in most cases can be done without.
But taking a flight from New York to LA is a need, without which a trip to New York airport really
doesn't make any sense. Needs are associated with the problems. The problems which the product needs
to solve for the end user. Now in a typical requirement discovery session most of what
you hear from the stakeholders are actually wants and not needs. A good practice therefore is to dig
a little deeper to get to the root cause of the problem to be solved. Now there are several tools
to help you do just that but my favorite is 5 WHYs. The idea of needs over wands ties really
nicely to the Agile principle of Simplicity which is also the fifth and the final best practice of
Agile Requirements Discovery. Simplicity simply means limiting the solution to what is just
barely good enough to solve a problem. Going far beyond the optimum point of users' needs
to develop a solution will not only increase the scope and complexity of the development effort
but beyond this point adding additional features has diminishing value. It is a
good practice to start with the simplest and the most basic solution possible and then add
to it incrementally and iteratively only to the extent that it adds value to the user. So there
you have it. Before you go here's a quick shout out to Marcelo for translating the subtitles of
6 communication tips for Scrum Masters video into Brazilian Portuguese. On behalf of the
Brazilian Agile Community I would like to say thank you Marcelo that means a lot. Link to
Marcelo's LinkedIn profile is in the description. So that's it yeah thanks for watching if you like
this video and you want to see more stuff that's on the YouTube you should check out the video
over here which is all about the psychology behind the resistance we face during Agile Transformation
and one way to fix it. Thank you so much for watching and I will see you in the next video.