Seven Steps to Agile Business Analysis Domination
/
My hunch is that you don’t want to be an Agile “noob” forever. And you won’t be, don’t worry. It takes a ridiculously short period of time for people to get up to speed with Agile. The challenge is getting to the next step – excelling.
I want to accelerate this for you. I want you to be a superior Agile BA as soon as possible.
BAs new to agile environments typically make seven big mistakes. If you avoid them, you’ll be well on your way to success (and avoid some pain along the way).
Normally, I would break this out into several tips, but today is the last day, and I want you to have it all. Here goes…
1. Be more lean with documentation
If you’re not familiar with Lean, please check it out. At the highest level, Lean is about identifying waste in the organization and removing it so that you can most efficiently deliver value to your customers.
What does this mean in an agile context? Think of all the activities you perform during the work day. Do they all contribute to your product being better in the eyes of your customers?
We spend a lot of time writing user stories and acceptance criteria. Don’t go overboard with this. Write just enough.
If your user story doesn’t fit on one side of an index card (about 30 words) and its acceptance criteria on the other (about 70 words), you’re probably wasting ink and time.
2. Keep your eye on the big picture
Remember from yesterday, that we need to have agile requirements practices, and we need to use progressive elaboration as requirements change.
Therefore, focus on your epics, your big features. Keep a running tally of the most important ones in your head. Keep an eye on how long it takes an entire epic to be delivered, not just on the velocity of user stories. This is one of the ways the BA can add the most value to the PO and team (and customer).
3. Analyze the customer’s needs
This sounds like a no-brainer. This is our job description, right?
But it’s incredibly easy for BAs to trust the Product Owner’s opinions of what the customer needs, without doing a deeper analysis. And the rapid cycle times of agile iterations can make analysis more challenging.
You need to do two things here:
You have to stay in contact with actual customers and users of your product. The PO cannot be the bridge between customers and the team. No one person can be.
And you have to keep your analysis relatively quick and light compared to waterfall environments. Timebox everything. Drive everything to a conclusion.
4. Model potential solutions
Modeling is an area that BAs frequently overlook, no matter what style of project they run. If you have ever worked on a project where you implemented a process, and it didn’t work in the real world as well as it did on paper, this was probably a modeling problem.
Before implementing a decision tree or process or any other complex entity, model it with a wide range of scenarios.
But just like analysis, keep this relatively quick and light.
5. Test your assumptions
Hopefully, you have a good idea of what your customers want, of what they need, of how they think, and of how they make decisions. After all, you’re spending time with them regularly, gathering their feedback, and listening and observing them.
But this mental model of your customer is necessarily far from perfect. And it’s a waste of time, energy, and money to build features that they won’t value.
So, test your assumptions. Do mini-experiments. Listen to what they say, but remember that what they say and do are often different things.
6. Take responsibility for the team’s velocity
If you haven’t come across the term velocity, it’s essentially how many story points can be delivered in a sprint. The higher our velocity, the more quickly we can deliver valuable features to our customers.
Velocity is dependent on a number of factors: team talent and expertise, the tool set and platform available to the team, working conditions, team dynamics, and many more.
But some of these are directly under your influence: resolving spikes quickly, proactively understanding your customers, helping the PO to make quick (and good) decisions, and other areas you’ll find within your specific situation.
You are part of the team – no matter what your role – and the more effective they are, the more everyone benefits.
7. Continuously improve yourself
Continuous team improvement is part of Agile. It’s built into the various methodologies. In Scrum, we have a retrospective at the end of each sprint, and it’s probably the most valuable meeting the team has over the long term.
But at the end of each sprint, you also need to continuously improve yourself. What was the biggest area in which you underperformed? Document it, and improve it.
By now, everyone knows that we need to improve ourselves constantly. But do you actually have a process in place to make sure you do it? When was the last time you really examined your work and how it’s going? Are you reading the blogs? Are you taking the courses? Are you making professional contacts? Why not?
The bottom line is that you’ll never be excellent until you put this in place. Excellence is a process and way of life, not something that you attain once and forget about.
Subscribe