What is an Agile Business Analyst?
From this blog’s perspective, we will use the term “Agile Business Analyst” as the Business Analyst who works in “Agile based projects”. Agile business analysis is a systematic and disciplined approach to the specification and management of requirements with the following goals:
1. Knowing the relevant requirements, achieving a consensus among the stakeholders about them, documenting them according to given standards, and systematically managing them.
2. Understanding and documenting the stakeholders’ desires and needs, they specify and manage requirements to minimize the risk of delivering a system that does not meet their desires and needs.
Agile business analysts are primarily involved in the following activities:
1. Act as shadow product owner
2. Interact with stakeholders to gather their needs
3. Understand requirements from other sources
4. Elaborate stakeholder requirements to solution requirements
5. Ensure requirements quality
6. Develop acceptance criteria
7. Test fulfillment of requirements
Why do traditional waterfall projects fail?
Agile is probably the biggest buzzword in the software development industry. But what is agile? Before Agile, we had plan-driven approaches such as a Project Management Body of Knowledge (PMBoK) or Capability Maturity Model (CMMI).
Traditional waterfall worked in the following manner:
These projects would have a dedicated requirements phase which may take anywhere between 3 months to 6 months. Then an equal amount of time would be spent on design. Construction would be double the time, and testing would be similar to the requirements phase. Deployment would be slightly smaller. Overall, we would end up with project durations ranging anywhere between 2 to 4 years. These are typical numbers; sometimes, projects can even be 5 years long.
Over this long period, a few things happen:
1. There are changes in the need due to changes in the marketplace.
2. Market places are changing rapidly due to rapid changes in technologies.
3. Stakeholders did not have any opportunity to use and provide feedback on the product. Finally, when they get to see the product, they discover many aspects.
4. It is extremely difficult to specify requirements, especially with respect to usability aspects, unless one uses the product.
Plan-driven approaches had a fixed goal, and the project tried to meet the goal. All these finally result in a product that doe not meet the stakeholders' needs. Now too many change requests come up (I have seen projects where 600 change requests were raised during UAT). So the project budget needs to be revised, and the project misses its deadline. Also, the older methods demanded a large amount of documentation to be created upfront, which literally goes waste due to such a high number of changes.
The problem with software products is users find it really hard to specify their requirements well. All these issues forced software practitioners to look for something that can overcome issues with the waterfall approach.
How can we fix issues that failed with the traditional waterfall model?
The key drawback of the traditional waterfall model was its inordinately long duration. The 2nd major drawback was that stakeholders typically saw the product at the end of the project. Now, what happens if we divide the projects into many short waterfalls? This is exactly what agile does. Agile is essentially a waterfall in shorter cycles.
There are 2 major advantages:
1. We can course correct our plans if our needs change.
2. Get user feedback in a prompt manner.
If you observe the above diagram, the team changed its course mid-way to achieve the new goal. If the scrum team had followed the original plan, it would have reached a place that stakeholders no longer desired.
The use of the word agile in this book is derived from the agile manifesto.
Simply put, agile development is a different way of managing IT development teams and projects.
A small group of software developers got together in 2001 to discuss their feelings about the traditional approach to managing software development projects. Projects were failing far too often as they did not meet user expectations. They came up with the agile manifesto, which describes 4 important values.
The agile manifesto says:
Individuals and Interactions over processes and tools
Working Software over comprehensive documentation
Customer Collaboration over contract negotiation
Responding to Change over following a plan
That is, "while there is value in the items on the right, we value the items on the left more.”
Principles behind the Agile Manifesto
1. Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals.
6. Give them the environment and support they need, and trust them to get the job done.
7. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
8. Working software is the primary measure of progress.
9. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
10. Continuous attention to technical excellence and good design enhances agility.
11. Simplicity - the art of maximizing the amount of work not done is essential.
12. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the scrum team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Some more principles that can be followed during agile projects are:
1. Stakeholders collaborate and cooperate for project success.
2. Active user involvement is extremely critical.
3. Business sets priorities.
4. Requirements can always remain fixed for an agreed period.
5. Capture initial requirements at a high level; keep them lightweight and visual.
6. Develop small, incremental releases and iterate.
7. Focus on frequent delivery of products.
8. Complete each feature before moving on to the next.
9. Testing is embedded in every iteration – test early and often.
Now, what’s Scrum?
Scrum is an agile development method that concentrates particularly on how to manage tasks within a team-based development environment. Scrum is the most popular and widely adopted agile method. This is because it is relatively simple to implement and addresses many of the management issues that have plagued IT development teams, for decades.
A scrum team typically consists of around seven people who work together in short, sustainable bursts of activity called sprints, with plenty of time for review and reflection built-in. One of the mantras of scrum is “inspect and adapt,” and scrum teams are characterized by an intense focus on continuous improvement—of their process but also of the product.
Let us understand parts of scrum: the various roles, artifacts, and events that occupy the sprint cycle.
Scrum recognizes only three distinct roles: product owner, scrum master, and team member:
The product owner is responsible for maximizing the return the business gets on its software development investment (ROI). She achieves it by directing the scrum team toward the most valuable work. The product owner controls the implementation order, called priority in the product backlog. In scrum, only the product owner is authorized to change the product backlog.
A product owner is responsible for developing requirements, often in the form of user stories (egg, “As a <role>, I want <a feature>, so that I can <accomplish something>”) and adding them to the product backlog. Each of these user stories, when implemented, will incrementally increase the value of the product.
Product Owner Role in a nutshell:
* holds product vision represents the interests of the business
* represents business and customers
* owns the product backlog
* orders (prioritizes) the items in the product backlog
* creates acceptance criteria for the backlog items
* is available to answer team members’ questions
The scrum master acts as a coach, guiding the scrum team to ever-higher levels of cohesiveness, self-organization, and performance. Scrum master’s deliverable is a high-performing, self-organizing team. She is the team’s good guide, champion, guardian, facilitator, and scrum expert. She helps the scrum team learn and apply scrum-related practices to the team's best advantage.
She is constantly available to the scrum team to help them remove any impediments or roadblocks that keep them from doing their work. She is not on the scrum team. This is a peer position on the team, set apart by knowledge and responsibilities, not rank.
Scrum Master role in a nutshell: scrum expert and advisor, coach, impediment remover, facilitator
Scrum Team Member
High-performing scrum teams are highly collaborative and also self-organizing. Team members doing the work have total authority over how the work gets done. They decide which tools and techniques to use and which team members will work on which tasks. They create task estimates.
The scrum team should possess all skills needed to create a potentially shippable product. This means the Scrum team will have a team of specialists, each contributing to the team's success. They do their specialist work most often but also work outside their area of specialty to complete backlog items. They need a mindset change from "doing my job" to "doing the job." It is also a change in focus from "what we are doing" (work) to what is getting done (results).
Team Member Role in a nutshell:
* responsible for completing user stories to incrementally increase the value of the product
* self-organizes to get all of the necessary work done
* creates and owns the estimates
* owns the “ how to do the work” decisions
* avoids siloed “not my job” thinking
Common Scrum team size is seven, plus or minus two. That is, from five to nine. Fewer team members and the scrum team may not have enough variety of skills to do all of the work needed to complete user stories. More team members and the communication overhead start to get excessive.
The product backlog is the list of desired deliverables for the product. This includes features, user stories, bug fixes, documentation changes, and anything else that might be meaningful and valuable to produce. The product backlog is ordered such that the most important backlog item, the one that the scrum team should do next, is at the top of the list. Then comes 2nd, then 3rd, and so on.
Each story includes the following information:
1. Which users will benefit from the story (who it is for)
2. Brief description of the desired functionality (what needs to be built)
3. Reason why the story is valuable (why we should do it)
4. An estimate of work the story requires to implement
5. Acceptance criteria to determine that the story has been implemented correctly
The sprint backlog is the team’s to-do list for the sprint. Sprint has a finite life span, anywhere between 2 weeks to 2 months. Sprint backlog includes the stories that the scrum team has committed to delivering this sprint and their associated tasks. Stories are deliverables and are units of value. Tasks are things that must be done in order to deliver the stories, and so tasks can be thought of as units of work. A story is something a team delivers; a task is a bit of work that a person does. Each story will normally require many tasks.
A burn chart shows us the relationship between time and scope. Time is on the horizontal X-axis, and scope is on the vertical Y-axis. A burn-up chart shows us how much scope the scrum team has got done over a period of time. Each time a deliverable/task is completed the line on the chart moves up.
A burn-down chart shows us what is left to do. In general remaining goes down over time as the scrum team gets things done.
Task boards make the team's tasks visible to everyone. The simplest task board consists of three columns: to do, doing, and done. Tasks move across the board, providing visibility regarding which tasks are done, which are in progress, and which are yet to be started.
Definition of Ready
Definition of ready defines what should be done before the team starts working on a story. This may include aspects such as having the story meet the INVEST criteria, have acceptance criteria developed and the story explained to the Scrum team.
Definition of Done
Definition of done defines what should be completed to declare a story to be done. This may include aspects such as code written, code reviewed, unit tests passing, regression tests passing, documentation written, product owner sign-off, and so on.
The Sprint cycle is the foundational rhythm of the scrum process. This may be called a sprint, a cycle, or an iteration. This is a fixed period of time within which the team completes a few backlog items. At the end of each sprint, the scrum team should deliver a potentially shippable product increment. That is the quality high enough that the business could ship it to customers.
The more frequently the scrum team delivers and demonstrates a potentially shippable product increment, the more frequently the scrum team gets feedback, which fuels the important inspect-and-adapt cycle.
Sprint Planning Meeting
Sprint planning marks the beginning of the sprint. During sprint planning, the scrum team commits to a set of deliverables for the sprint. Then the scrum team identifies the tasks that must be completed in order to deliver the agreed-upon user stories. We recommend one to two hours of sprint planning per week of development. The output of the sprint planning meeting is the sprint backlog, a list of all the committed stories with their associated tasks. The product owner agrees not to ask for additional stories during the sprint unless the scrum team specifically asks for more.
Daily Scrum / Daily stand-up meeting
Daily scrum, sometimes called the stand-up meeting, is Daily. Most teams choose to hold this meeting at the start of their workday. The daily scrum is limited to 15 minutes.
Each participant quickly shares:
1. Which tasks I've completed since the last daily scrum.
2. Which tasks do I expect to complete by the next daily scrum.
3. Any obstacles are slowing me down.
The goal of this meeting is to inspect and adapt the work the scrum team members are doing in order to successfully complete the stories that the scrum team has committed to delivering.
In this meeting scrum team discusses stories in the product backlog, which contains all the stories for future sprints with the product owner. Recommended one hour per week. In this meeting, the scrum team works with the product owner on:
Each user story in the product backlog should include a list of acceptance criteria. These are pass/fail testable conditions that help us know when then the story is implemented as intended. Some people like to think of them as acceptance examples: the examples that the scrum team will demonstrate to show that the story is done.
Story Sizing (Estimation)
During storytime, the scrum team will assign a size (estimate, if you prefer that term) to stories that haven’t yet been sized. This is the team's guess at how much work will be required to get the story completely done.
Stories at the top of the product backlog need to be small. Small stories are easier for everyone to understand and easier for the scrum team to complete in a short period of time. Stories further down in the product backlog can be larger and less well defined. This implies that we need to break the big stories into smaller stories as they make their way up the list. While the product owner may do much of this work on their own, storytime is their chance to get help from the whole team.
As of this writing, the storytime meeting isn’t an 'official' scrum meeting. We suspect it will be in the future, as all of the high-performing scrum teams we know use the storytime meeting to help keep their product backlog groomed.
This is the public end of the sprint; invite any and all stakeholders to this meeting. It's the team's chance to show off its accomplishments, the stories that have met the team's definition of done. This is also the stakeholders’ opportunity to see how the product has been incrementally improved over the course of the sprint.
If there are stories that the scrum team committed to but did not complete, this is the time to share that information with the stakeholders. Then comes the main event of this meeting: demonstrating the stories that did get done. Undoubtedly the stakeholders will have feedback and ideas, and the product owner and the scrum team members will gather this feedback, which will help the scrum team to inspect and adapt the product.
This meeting is not a decision-making meeting. It's not when we decide if the stories are done; that must happen before this meeting. It's not when we make decisions or commitments about what the scrum team will do during the next sprint; that happens in sprint planning.
How long should the sprint review be? We recommend scheduling one-half to one hour for every week of development. That is, if you have a one-week sprint, then this meeting might be 30 – 60 minutes. If you have a two-week sprint, then this meeting might need one to two hours. After doing it a few times, you will know how long your team needs to inspect and adapt!
Retrospective, held at the very end of each and every sprint, is dedicated time for the scrum team to focus on what was learned during the sprint and how that learning can be applied to make some improvement. Recommended one to two hours of retrospective time for each week of development.