8 Agile and Scrum
The previous chapters presented Business Analysis techniques that work in any methodology. Now we focus specifically on Agile environments, where Business Analysis adapts to iterative, collaborative approaches that dominate modern software development.
8.1 The Agile Mindset
Agile is not just a methodology. It is a mindset that values certain principles over traditional approaches.
Agile values individuals and interactions over processes and tools. This does not mean processes and tools are unimportant. It means that when forced to choose, we prioritize people.
Agile values working software over comprehensive documentation. Again, documentation has value. But working software that meets user needs matters more than perfect documents that describe software that does not exist.
Agile values customer collaboration over contract negotiation. Relationships and ongoing dialogue produce better outcomes than rigid contractual requirements.
Agile values responding to change over following a plan. Plans are useful, but the ability to adapt when circumstances change is more valuable than stubbornly following an outdated plan.
8.2 Why Agile Emerged
Traditional software development often followed the Waterfall approach: gather all requirements, complete all design, build everything, then test. This approach works well when requirements are stable and well-understood.
But many software projects do not fit that profile. Requirements are unclear at the start. User needs evolve as they see working software. Technology changes rapidly. Competition demands quick responses.
Agile emerged to address these realities. Instead of trying to predict everything upfront, Agile embraces uncertainty. It delivers working software in short cycles, learns from each delivery, and adapts based on what is learned.
8.3 Scrum: The Dominant Agile Framework
Scrum (Figure 8.1) is a lightweight agile project management framework mainly used for software development. Its goal is producing the highest business value in the shortest time.
Scrum organizes work into sprints, which are time-boxed iterations typically lasting one to four weeks. At the end of each sprint, the team delivers a potentially shippable product increment.
8.4 Scrum Roles
Scrum defines three roles (Figure 8.2), each with specific responsibilities.
8.4.1 Product Owner
The Product Owner represents the customer and stakeholders. This person owns “what” and “why” the team builds things.
Responsibilities include managing the product backlog (creating, maintaining, and prioritizing items), communicating the product vision to the team, deciding on releases, managing stakeholder expectations, monitoring progress, and making decisions about what to build.
The Product Owner must be available to answer questions and make decisions. When the Product Owner is unavailable or indecisive, the team stalls.
8.4.2 Scrum Master
The Scrum Master facilitates the Scrum process. This person helps the team follow Scrum practices, removes obstacles that block progress, and protects the team from external distractions.
The Scrum Master is not a project manager who assigns tasks. Instead, the Scrum Master enables the team to self-organize and coaches them on continuous improvement.
8.4.3 Development Team
The Development Team consists of professionals who do the work of delivering the product increment. Team members own “how” and “how quickly” work is delivered.
The team is typically five to nine members. Teams smaller than five may lack necessary skills. Teams larger than nine have too much coordination overhead.
Effective Scrum teams share several characteristics. They share norms and rules. They hold each other accountable for delivery. They work as autonomously as possible. They are empowered to make decisions. Skills are shared rather than siloed. Members ideally work full-time on the team.
8.5 Scrum Events
All Scrum events are time-boxed, meaning they have a maximum duration that cannot be exceeded.
8.5.1 The Sprint
The sprint is the heart of Scrum. It is a time-boxed iteration, typically one to four weeks, during which the team creates a potentially shippable product increment.
Sprints have goals that define what the team aims to accomplish. The “definition of done” establishes criteria for determining whether work is complete.
Sprints should not exceed one calendar month because longer periods increase the risk that requirements will change before delivery.
8.5.2 Sprint Planning
Sprint planning occurs on the first day of each sprint. The team decides what work to commit to during the sprint.
The Product Owner presents the highest-priority items from the product backlog. The Development Team discusses what they can accomplish and selects items for the sprint backlog.
For a two-week sprint, sprint planning typically takes about four hours.
8.5.3 Daily Scrum
The daily scrum is a fifteen-minute meeting held every morning at the same time. All Development Team members attend. The Scrum Master facilitates. The Product Owner may attend but is not required.
Each team member answers three questions: What did I accomplish yesterday? What will I work on today? What obstacles are blocking my progress?
The daily scrum is not a status meeting for management. It is a coordination meeting for the team.
8.5.4 Sprint Review
The sprint review occurs near the end of the sprint. The team demonstrates what they accomplished to the Product Owner and stakeholders.
The Product Owner determines whether the increment meets acceptance criteria and decides whether to release it.
For a two-week sprint, the review typically takes about two hours.
8.5.5 Sprint Retrospective
The sprint retrospective occurs at the end of each sprint. The team reflects on how they worked together and identifies improvements.
Common retrospective questions include: What should we start doing? What should we stop doing? What should we keep doing?
For a two-week sprint, the retrospective typically takes about ninety minutes.
8.6 Scrum Artifacts
8.6.1 Product Backlog
The product backlog is a prioritized list of everything the product might include. The Product Owner owns this list and is responsible for its content and prioritization.
Backlog items are ordered by value, with the highest-value items at the top. Items at the top are refined and ready for development. Items lower in the backlog may be less detailed.
8.6.2 Sprint Backlog
The sprint backlog contains the items the team has committed to complete during the current sprint. The Development Team owns this list and decides what to include based on their capacity.
The Product Owner and Scrum Master should not dictate what goes into the sprint backlog. The team that does the work estimates the work and commits to it.
8.6.3 Product Increment
The product increment is what the team delivers at the end of each sprint. It must be potentially shippable, meaning it meets the definition of done and could be released if the Product Owner chooses.
The Product Owner decides whether to actually release each increment or wait until more features are complete.
8.7 Scrum Values and Pillars
Scrum rests on three pillars (Figure 8.3).
Transparency means that significant aspects of the process are visible to those responsible for outcomes. Everyone sees the same information.
Inspection means frequently checking progress toward sprint goals to detect problems early.
Adaptation means adjusting processes as soon as problems are detected to minimize further deviation.
Scrum values support these pillars: commitment to achieving goals, courage to do the right thing, focus on sprint work, openness about challenges, and respect for team members.
8.8 The Minimum Viable Product
The Minimum Viable Product (MVP) is a product that includes core features without advanced features. It solves the problem and can be used, but only includes what is absolutely necessary.
The MVP concept enables early delivery and learning. Instead of waiting until everything is built, teams deliver the minimum that provides value, then learn from user feedback and iterate.
Think about it this way: the MVP for a lightbulb might be a candle. The goal of producing light is accomplished. Then you iterate toward better solutions.
8.9 User Personas
A user persona is a representation of a type of customer. Personas help teams understand who they are building for and make better decisions about features and priorities.
Personas typically include demographic information, goals and motivations, frustrations and pain points, and behavioral patterns. They are based on research with actual users, not assumptions.
8.10 The Business Analyst in Scrum
Where does the Business Analyst fit in Scrum? The framework does not define a Business Analyst role. Business Analysis work still happens, but it is distributed differently.
In some organizations, the Business Analyst serves as the Product Owner or assists the Product Owner with backlog management and stakeholder communication.
In other organizations, the Business Analyst is part of the Development Team, contributing analysis skills to refining user stories, defining acceptance criteria, and ensuring requirements are understood.
The key is that Business Analysis competencies remain valuable regardless of how roles are structured. Someone must understand stakeholder needs, translate them into requirements, and ensure solutions deliver value. Scrum changes how this work is organized, not whether it is needed.
8.11 Case Example: The Mobile Banking App
First Regional Bank decided to build a mobile banking app. They chose Scrum because requirements were unclear, competitors were moving quickly, and user expectations were evolving.
The Product Owner was a senior banker who understood customer needs. The Scrum Master was an experienced agile coach. The Development Team included developers, testers, a UX designer, and a Business Analyst.
The Business Analyst focused on refining user stories. When the Product Owner said “customers should be able to transfer money,” the Business Analyst asked clarifying questions. Between which accounts? With what limits? What confirmation is needed? What happens if the transfer fails?
These conversations produced detailed acceptance criteria that the Development Team could implement and test.
Sprint 1 delivered basic account viewing. Sprint 2 added internal transfers. Sprint 3 added external transfers. Sprint 4 added bill payment. Each sprint produced working software that users could test.
User feedback after Sprint 2 revealed that the transfer confirmation screen was confusing. The team adjusted the design in Sprint 3. If they had followed Waterfall, this problem would not have been discovered until after full development was complete.
The app launched after twelve sprints. It was not feature-complete compared to competitor apps, but it met core user needs. Subsequent sprints added features based on actual user feedback rather than assumptions.
Now that you understand how Business Analysis adapts to Agile environments, let us apply what you have learned through hands-on modeling exercises.
8.12 Review Questions
In Scrum, who is responsible for managing and prioritizing the product backlog?
- Scrum Master
- Product Owner
- Development Team
- Project Manager
What is the typical duration of a daily scrum meeting?
- One hour
- Thirty minutes
- Fifteen minutes
- As long as needed
What does MVP stand for, and what does it represent?
- Most Valuable Player; the best team member
- Minimum Viable Product; a product with only core features
- Maximum Value Proposition; the full feature set
- Managed Version Plan; the release schedule
Which Scrum event focuses on how the team worked together and identifies improvements?
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
The three pillars of Scrum are:
- Planning, Execution, Delivery
- Transparency, Inspection, Adaptation
- Commitment, Focus, Respect
- Backlog, Sprint, Increment
1-b, 2-c, 3-b, 4-d, 5-b