Is your team struggling with the transition to modern requirements practices? As many teams explore and experiment with modern practices and agile, they often jump to apply tactical methods and techniques. But does anything really change?
Most teams work really hard and don’t see results. Or they find a few early benefits, but get stuck on a low plateau. They often give up and slide back into their old habits. Why? Because they’ve modified surface-level tactics, but haven’t modified mindsets.
Transformation begins in the brain. To transform your team’s approach to deliver true value, you need to change the way they think. When they think about requirements and solutions from new perspectives, their behaviors, attitudes, conversations and tactics will start shifting, and that’s where authentic transformation begins.
Start your transformation by changing your thinking in these three ways:
Less Feature Thinking and Move to More Value Thinking
Takeaway: Focus on value more than features.
How do you start your requirements process? Many agile and traditional teams start their process by brainstorming features. While I don’t always disagree with this approach, it’s a potentially dangerous and slippery slope if teams are not careful. The mindset or context you use to begin your requirements process has a huge impact on the time, cost, and quality of the product or solution. It is easy to over engineer features and miss the value the feature is meant to provide.
The problem is not the feature-thinking itself, but what gets shoved aside when features dominate the thoughts and dialog of stakeholders. In most cases, a focus on features pushes value to the sidelines—we forget about the value the solution brings to our users and our organization. We often miss what it is about the feature that brings the intended value stakeholders and users need.
Teams do NOT build solutions; they solve problems. What might happen if the team remains focused on the solution and its detailed features instead of the opportunity to solve the end user’s problem? Teams might:
- exceed what is needed from a minimum viable product perspective
- get distracted by secondary features and compromise the quality of the features that have a direct impact on the problem/opportunity
- waste time and money
- create a product that has so many bells and whistles that users are overwhelmed, don’t use the solution, and continue to use old tools, manual workarounds or redundant processes.
Features can help teams discuss the problem or opportunity at a high level, but features by definition are a functional capability of the solution. When teams operate in a feature mindset, they tend to jump to technical details, and these are details we want to avoid...especially in the early stages of a project. When discussing features, be sure to ask: What part of our problem will this solve or what aspect of our opportunity will this help us take advantage of? If this focus is lost, value is compromised. Features maximize value when they align with and are prioritized based on the core mission of the organization and the needs of the customers. It’s all about creating happy customers and a thriving business.
Ditch Inside Out Thinking and Move to Outside In Thinking
Takeaway: Focus on users not the project team.
Another pitfall that takes our focus away from providing value to the organization and the end user is inside out thinking. When we get bogged down by the day-to-day details of delivery, our focus shifts to the internal needs of the delivery team and system details (inside out thinking) and we lose sight of our end users problems (outside in thinking). We start talking about protocols, databases, interfaces, integrations, and upgrades, instead of user needs, user preferences, user priorities and user experience.
Great analysts use a wide variety of techniques to help their team keep user experience top-of-mind, but here are a few suggestions:
- Create, build, and analyze personas, and their linkage to value and strategy.
- Use empathy maps to analyze value and user experience.
- Organize user stories by user value, not technology component.
- Slice and dice iterations based on chunks of user value, not by system, database, interface, protocol, etc.
- Allow users to interact with prototypes.
- Get input/feedback from user focus groups.
- Build user stories that are truly from a user perspective and show business value.
- Ask user-focused questions: How will this benefit the user? Does this feature align with the top 3 user goals? How could we improve the user experience?
Ditch Isolated Thinking and Move to Collaborative Thinking
Takeaway: Don’t do requirements in isolation. Collaborate until you reach shared understanding THEN document.
When I ask teams to estimate the % time they are spending on the five common requirements activities (planning, eliciting, analyzing, documenting and reviewing) it often results in a pie like this:
That huge chunk of documentation time tells the sad story of isolated thinking—a lonely analyst spending most of their time in their cube cranking out requirement templates with little input from others. What does this lead to?
- Endless rounds of review and rewrite!
- Frustrated stakeholders and analysts who endure scope changes, rework, an ever-growing backlog.
- Sad users who wait and wait and wait for solutions to their problems.
We need to spend less time documenting and reviewing! Documenting and reviewing are low impact forms of communication and collaboration. Instead we need to create a culture of collaborative thinking that:
- provides context/big picture
- helps stakeholders connect the dots
- helps stakeholders identify gaps
- inspires critical thinking and innovative problem solving
Instead of starting with text-based requirements templates, we should use elicitation and analysis techniques that inspire meaningful dialog including visual models, matrices and collaboration games.
It may seem counter intuitive, but spending more time on the front-end of your requirements to create shared understanding before cracking open that formally documented end state, will speed up the write/review/validate process. If you get everyone on the same page first with effective elicitation and analysis, then documentation and review become a rubber stamp and requirement processes will be more effective and efficient.
A better mix for all teams (agile, traditional and hybrid) looks something like this:
Documenting and reviewing, when everything else is done right, should take less than 5-10% of total requirements time. We need to guide stakeholders through the process, a process we own as analysts. We must advocate for the importance of planning, elicitation, and analysis and share the risks of reducing or skipping these activities.
Author: Angela Wick CBAP, PMP, PBA, Founder & CEO, BA-Squared, LLC
Angela Wick CBAP, PMP, PBA is the founder and CEO of BA-Squared, LLC, a training and consulting company that helps organizations modernize their requirements practices. With over 20 years’ experience she helps traditional, agile and hybrid teams develop skills they need to build the right solutions that deliver the intended value to users and organizations. Find out how Angela can help you by visiting BA-Squared.com. Get free requirements tips and resources by following Angela in Twitter @WickAng.