From the course: Agile Requirements Foundations

Agile principles 5–8 from a business analyst perspective

From the course: Agile Requirements Foundations

Agile principles 5–8 from a business analyst perspective

“

- Okay, so we have seen agile principles one through four, and we are seeing how important these are to BAs as part of the agile team. Next let's look at principles five through eight. Number five, build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. BAs serve the user, customer, and the organization. They help the team understand each piece of work and how it aligns to the vision. They help the product owner prioritize, make decisions, balance trade-offs, and remove features or work that doesn't align with the product vision. On agile teams, BAs are empowered to be part of us by facilitating collaborative requirements, techniques that invoke deep conversations. BAs also are empowered to facilitate conversations and document just enough at the last responsible moment. Next number six. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. On agile teams, BAs don't hand off requirements and stories to developers. Requirements are based on conversations. Documents or details typed into a tool are placeholders for conversation or memories of conversations. The team collaborates on a daily basis to understand stories and features. The BA uses conversations, facilitated sessions, and structured dialogue to keep the team engaged. Agile teams value face-to-face conversation with the team over documentation and hand offs. Virtual teams can also use many tools to facilitate face-to-face dialogue as well. Tools that use virtual whiteboards, virtual sticky notes and video are common for virtual agile teams. These virtual communication tools are much more powerful than document hand offs and simple voice conversations. Okay, next is number seven. Working software is the primary measure of progress. Agile teams demonstrate progress with working software, not documents about working software. We want the product owner, business analyst, and some user representatives to see working software as often as possible during the sprinter iteration. We want feedback associated with the working software to guide detailed requirements and designs. Agile teams prefer to finish increments of value instead of increasing the amount of work in progress. The BA demonstrates this principle via prioritized stories, well-defined acceptance criteria, prototyping and experimenting. BAs elicit feedback from users as the sprint progresses. And last, number eight. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely. BAs work on requirements just in time. This is not reactive work but actually quite proactive. BAs work with the product owner to understand the product vision and roadmap. The BA helps the product owner refine the backlog in the big picture view as well as the detailed views. The detailed views are only needed for the upcoming work items and BAs also help the teams size and estimate work. When the backlog is well refined, the planning and execution of an iteration flows smoothly and maintains a steady manageable pace. Now we've seen principles five through eight, and there are four more. And some of the best are still to come. So let's look at principles nine through 12.

Contents