We’re going to the dark side of business analysis and agile requirements today, and looking at how we really help out end users who still have a waterfall mindset get clear about their requirements.
This is the under-the-radar STUFF that very few people talking about. But it’s very much the reality of many of the business analysts I hear from. You absolutely, positively do not need to feel alone if you’ve dealt with this situation before or are dealing with it right now.
I’ll let you check out the video or transcript for the full context, but here are a few of the bullet points:
- Team is new to agile
- Approved BRD with vague requirements
- Expected end date
- Focus on minutia
Whew…that’s a lot, right? What would you do? Listen in to learn about my suggestions for moving forward quickly.
For those who like to read instead of watch, here’s the full text of the video:
The Agile Requirements Challenge
Today’s video is going to be a doozy because we are talking about what to do when your business team is still thinking waterfall, and you are in the middle of this, as a business analyst, needing to define requirements in an agile way and work within an agile software development team.
This question came to us straight from a member of our community. The name is Jean. Instead of me talking through it and embellishing it or thinking that I’m embellishing it, I’m going to read her question verbatim.
Jean says:
I’m working on a very large project and coming in after they’ve had the BRD review. We are new to the agile methodology. I’m trying to write user stories with unclear requirements and little training. So, it’s been a challenge. The chief product owners and business owners are not easily accessed. We are following the chain of command. They don’t understand or care what it’s going to take to get the project done. When we ask questions, they say, “Didn’t you read the BRD?” Got a lot of that one. Or send you to someone else. It’s not that simple, right, when you dive into the vague requirements? I keep trying to find ways to get this done and hit roadblocks, which make me feel very unsuccessful. As part of agile, we’re told to fail fast and fail early, but the business owners are still thinking waterfall. They have an end date, and they expect us to meet it. Plus, I’m co-product and my co-product owner is one that wants to drill into minutia, rather than focusing on the user stories and the product backlog.
Okay, so what would you do?
Getting to the Agile Requirements with Demos
Here’s what I would do. This might sound a little counter-intuitive, but I would take that BRD, the vague requirements that are in that BRD, and I would either demo the working software, if there is already working software. It sounds like there’s not. Or I’d create a set of wireframes. I would create wireframes that essentially model my current understanding of the requirements for a subset of the requirements. Then I would schedule a review meeting with those business stakeholders. You’re doing a few things with this technique.
One; you’re getting out of this. It’s in the BRD. You’re presenting a new deliverable that’s, obviously, taking the project forward. Everybody loves to look at a user interface, and everybody sees any user interface, like what’s missing, or what the gaps are. You have created a tool to get an immense amount of feedback quickly. You’re also modeling an agile practice when you do this. One of the big practices in agile is that you demo your working software.
Usually, it’s a working software, so the tech team would demo whatever they created in the sprint for their business users. But that, it sounds if the requirements are unclear, that could create a lot of waste. You’re dabbling in that practice, but you’re doing it in such a way where you’re creating a very throw away easy to create type of deliverable, a very low fidelity wireframe rather than a full-fledged working software system. You’re getting people into that practice of doing reviews, giving feedback, seeing early software representations, and using that as a tool to clarify the requirements.
Don’t Expect to Get the Wireframes “Right” the First Time
One word of warning on this, it’s going to take a bit of a thick skin because most likely, if those requirements are truly vague, or there are gaps in them, they’re going to be wrong. That is going to feel like, “Oh, I did something wrong.” But any time you’re putting a deliverable in front of a business user to get more information, to get more clarity, that’s what success looks like. Sometimes I like to equate wireframes, or any visual model, to coffee table books.
Do you put a coffee table book on the coffee table because you want your guests to sit and page through the whole thing, read the whole thing? No. It’s there because it represents a vacation you took or an interest you have, or something you found valuable. It’s there to create a conversation. It’s there so the guests may say, “Oh, you’ve been to Stonehenge. I went there so many years ago.” And, then all of a sudden, you’re talking and you’re having a conversation about something that’s meaningful to you both.
Wireframes and other visual models can work in, essentially, the same way. They’re conversation starters to get us out of question asking and critiquing, and this requirement isn’t clear enough and into what can we do to improve this model so that it fully represents what you want out of the software system.
Help Your Waterfall Stakeholders Transition to Agile One Step at a Time
The other thing is, once you have, then, those wireframes, that’s what you can use to create your user stories and your product backlog, and then you might start to see there’s a lot here. Can we prioritize some of these things? That’s that next level of education that you’ll want to do as an agile business analyst about how priorities and estimates work.
Quite honestly, that’s a bit that, as a business analyst, we’re facilitating priorities, and we’re facilitating the engagement in the priorities. But when it comes to the culture change that comes with agile, and the sponsor expects XYZ by X date vs. we prioritize, and we deliver the most important things first, and we’re not clear, or we can’t commit to what comes in by which date, that’s the project management tech team, whoever is leading agile in your organization needs to influence that kind of change in your organization.
You can step in as a business analyst and you can say, “Hey, it’s important now that we’re clear on our priorities because of how things are happening and these new processes we’re using. Let me make sure I understand your priorities and I’m going to help you prioritize this product backlog so that you get what’s most important to you. You can be a partner to the business and working with IT instead of having to feel like you are selling that part to IT. Try to sidestep that whole argument altogether, if you can.
Finally, the other note I had on this specific situation was, it sounds like you are a co-product owner, which that’s awesome. I love that there are two of you. You might be more big-picture thinker, and this other person might be more in the minutia, in the details. Can they be the one? You create the wireframes, maybe the first draft of the product backlog, help with that prioritization and getting things moving, and they can go and flash out all those details in user stories and almost treat you as a first past stakeholder to get some of those details, and then where you need to get more stakeholder involvement from the business as well.
Just a few thoughts for you, Jean. Definitely a challenging situation. Probably not uncommon. I’m recording a video on this because I believe a lot of people probably have this question about agile requirements and how to help our business stakeholders make the transition from this waterfall mindset to more agile, collaborative mindset. I do see so much potential for business analysts and organizations leveraging agile practices. I think it makes what we do as business analysts even more important. That’s why we’re recording a few videos this month on agile business analysis, specifically.
Again, I’m Laura Brandenburg, from Bridging the Gap. We help you start your business analysts career. Thanks for watching.
Download Your Free Guide – 10 Tips to Improve Stakeholder Engagement
And if you are looking for even more tips to manage difficult stakeholders, download this free guide. You’ll
- Save time and effort by clarifying the requirements more quickly.
- Build stronger relationships that elevate your reputation and career.
- Improve project outcomes by communicating more effectively.