From the course: Agile Requirements Foundations

Key agile mindsets of business analysts

From the course: Agile Requirements Foundations

Key agile mindsets of business analysts

“

- It's very difficult to change behavior. Just ask the parent of a strong-willed toddler. But it starts with changing minds. When BAs really embrace the agile values and principles, they shift from a traditional mindset to an agile mindset. This agile mindset drives changes in behavior that bring value to the team and improve the quality of solutions. Let's take a look at some common situations and explore how an agile BA would think and behave. Okay, the first scenario. Stakeholder adding to the current sprint. In this situation, you're an agile BA working with the team. And a key stakeholder comes to you with an item they want to fit in to the current sprint, but it was not originally planned for this sprint. They promise it's really, really small, but really, really important. They thank you in advance for getting it into the mix. So, how should an agile BA respond? Well, as an agile BA, I would ask to chat fact to face with the stakeholder to get more context. I would bring the product owner and iteration leader/scrum master into the dialogue as well. The product owner would determine the priorities, and the iteration leader would identify any impacts to the current content, value, and end dates. Then a decision could be made by the product owner and the team on if we can fit this in without impacting other items and the goal of the sprint. In many cases, it will have an impact. And the item will need to placed on the backlog and prioritized. If it's a top priority for the next sprint, something may need to be removed in the plans for the next sprint to accommodate it. And the next scenario. The developer needs more detail. In this situation, a developer is looking at a user story for the sprint that just started. She says she needs detailed documentation before she can get started working on it. How should an agile BA respond? As an agile BA, I would ask the iteration lead and developer to meet face to face with me to better understand the developer's concerns. I would confirm our commitment to iterations and getting feedback on working software instead of spending time developing detailed documents. I would work to ensure my acceptance criteria are clear and do some whiteboard huddles and drawings with the developer to talk through possible designs and communicate the intent and value of the user needs. I would also ask the developer if it would help to take a photo or create a quick diagram or mock-up of what we discussed, creating a memory of the conversation. And I'd quickly do so if it would help. I would also let the developer know I'm excited to see something to provide feedback on. And I would expect a few iterations of feedback within the next week to get to the right solution and design. These are common scenarios agile BAs find themselves in. Notice the face to face default of having a conversation over creating a detailed email or document response. No more hiding at your desk behind emails. Get out and get people talking. If you're virtual, grab a video call and talk face to face. It's all about the conversations.

Contents