Business Analysis in Agile Projects - ASPE Training · Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles: Kanban
25
Business Analysis in Agile Projects with Kris Ashton, CBAP, CSM Denver, CO
[French, from Latin agilis, from agere, to drive, to do] When I think about Agile I think about these antelope that live on the prairie near my home in Colorado. They have qualities of… Quickness, lightness, and ease of movement; nimble American Heritage® Dictionary of the English Language Having quick motion and being nimble Farlex Trivia Dictionary® Nimble, active, quick, lively, swift, brisk, supple, sprightly, lithe, limber, spry, lissom(e) Collins Thesaurus of the English Language
Agile Software DevelopmentA conceptual framework
Iterative and incremental developmentIterative and incremental development
Collaboration between self-organizing, cross-functional teamsCollaboration between self-organizing, cross-functional teams
Adaptive planning, evolutionary development and delivery, and a time-boxed iterative approachAdaptive planning, evolutionary development and delivery, and a time-boxed iterative approach
Rapid and flexible response to changeRapid and flexible response to change
The way we’re using the term here today is in relation to Agile Software Development. I’ve heard Agile called “A priority and value declaration, not a methodology or process or tool.” (Alistair Cockburn, Roman Pichler and Ellen Gottesdiener) Mike Cohn says it’s… “Conversation over documentation” (talking specifically about user story) The term was introduced by the Agile Manifesto in 2001 (a manifesto is a public declaration of principles, policies, or intentions) and essentially describes a conceptual framework: It’s a group of software development methods based on iterative and incremental development… …where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile promotes adaptive planning, evolutionary development and delivery, and a time-boxed iterative approach… …and encourages rapid and flexible response to change.
The Agile Manifesto
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Working software Comprehensive documentation
Processes and toolsIndividuals and interactions
over
over
Beck, Kent; et al. (2001). "Manifesto for Agile Software Development." Agile Alliance. www.agilealliance.org
That is, while there is value in the items on the right, we value the items on the left more.”
Processes and tools
Customer collaboration
Following a plan
Contract negotiation
Responding to change
over
over
Traditional Approaches…
Analysis
Design
Scope Definition
Design
Build
Test
830™Software Requirements Specification
830™Software Requirements Specification
830™Software Requirements Specification
Implement
Traditional approaches such as waterfall ask us to define the entire scope of a problem, and possibly its solution, all at one time at the start of a project. We discover high-level and mid-level requirements, and then we decompose everything to reveal the very detailed requirements that describe what features and functions the solution will provide. This often results in quite a lot of documentation, which eventually distills down into some kind of a requirements specification, business requirements document, or something like that. We ask our stakeholders to consume and understand all this documentation and to approve our description of their detailed requirements. With that approval, we continue on to the remaining phases of the project life cycle (SDLC), and eventually implement the solution.
830™ Requirements Specification
Tedious
“The system shall…”
“If possible, the system
will…”
TediousError-proneTime-consumingBoring to readDifficult to grasp the “big picture”
“If we have time (money,
people), we’ll try to…”
A typical requirements specification could be quite lengthy and be filled with such statements as “the system shall…,” “if possible, the system will…,” or “if we just had some more time/money/people, we’ll try to…” What’s the problem with this? Tedious Error-prone Time-consuming Boring to read Difficult to grasp the “big picture”
Often Leads To…
And if that’s not bad enough, by the time we put something into production and our stakeholders see it in action, they are very likely to come up with some new ideas or change some old ideas. We often call this “change of scope.” Is that really fair? How many times have we heard “my stakeholders don’t know what they want” yet we have a process that asks them to tell us everything, even things they don’t know or can’t see, right at the beginning.
What We Need Is…
What we need is a better, more fair, way to engage our stakeholders through the life of a project. I call this “The Long View.”
What We Can Give Stakeholders
A little later…
A lot later…
Now…
Soon…
A little later…
We need to think about what we can give our stakeholders now that would benefit them the most or provide for the things that they can clearly see now. Then as we move into the future, we think about what we can give them “soon,” what might come “a little later,” and what we can deliver “a lot later.” It’s kind of like looking off into the horizon—what we can see right in front of us is pretty clear, but the farther away the view, the more hazy it becomes. As we move closer and closer to it, it becomes more and more clear.
Slices of Cak
eSlices of Cak
e
Yum… who doesn’t like cake? Look at all those yummy layers.
A
D
S
A
D
S
A
D
S
A
D
S
Slices of SDLC
Analysis
Design
Scope Definition
A
D
S
A
D
S
A
D
S
A
D
S
A
D
S
A
D
S
D
B
T
I
D
B
T
I
D
B
T
I
D
B
T
I
Design
Build
Test
Implement Sprint
D
B
T
D
B
T
D
B
T
D
B
T
D
B
T
I
D
B
T
IRelease
2-4 week Sprint
Agile is like taking a slice through a traditional development life cycle. We’re still going to do all of the work of all the phases, but we’re going to do it in smaller increments. In the first increment, we’ll define the features and functions that have the highest business value to our stakeholders and develop those into something that we could implement. We call this increment a “sprint,” and it’s typically completed in anywhere from two to four weeks. In the next sprint, we take the next-highest value items and implement those. If we didn’t want to issue new functionality quite so frequently, we could store up everything we’ve done for a few sprints and then issue it all at once, in one big release. Agile offers the flexibility to do whatever works best for the situation.
Scrum52%Lean
2%
Custom Hybrid
9%
Others10%
Don't Know8%
Agile Flavors
XP2%
Scrum/XP Hybrid
14%
Kanban3%
Source: 2011 State of Agile Survey, VersionOne.
Now, when people think of Agile they often have a particular type or flavor of Agile in mind. Here’s a study that was done by VersionOne that shows the distribution of Agile approaches in use in 2011.
Scrum Framework
R1
Release Planning Daily Scrum
24hr
Done yesterday?Doing today?
Impediments?
What can we KRAC about our
process?
$$
R1
R2
R3
Product Backlog
Sprint Backlog
Sprint2-4wk
Potentially Shippable Product
Sprint Planning
Sprint Review
Since the majority of Agile projects are done using Scrum or some Scrum hybrid, let’s take a couple of minutes to lay down a foundation for how Scrum works. Other Agile variations, as we’ll see, essentially add other capabilities on top of this basic framework. The business stakeholder has an idea and has some money. etc….. the story continues…
XP (eXtreme Programming) uses the basic Scrum framework and adds these capabilities: Pair programming—two developers work together on the same code Test driven development—write tests first, then write code Continuous integration—one code source, everyone uses the same latest build Simple design—no “clever code” Refactoring—simplifying and reusing code whenever possible Coding standards—everyone does it the same way And a few other key concepts: Frequent communication—with each other, other team members and business partners Courage—to say when something is wrong Respect—to listen when someone says something is wrong Embrace change—able to inspect our work and adapt as needed; continuously improve
Lean
Eliminate wasteAmplify learning
Decide as late as possibleDeliver as fast as possible
PurposeProcessPeople
Deliver as fast as possibleEmpower the team
Build integrity inSee the whole
The term "lean" was coined to describe Toyota's business during the late 1980s by a research team headed by Jim Womack, Ph.D., at MIT's International Motor Vehicle Program. Purpose, Process, People�Womack recommend that managers and executives embarking on lean transformations think about three fundamental business issues that should guide the transformation of the entire organization: - Purpose: What customer problems will the enterprise solve to achieve its own purpose of prospering? - Process: How will the organization assess each major value stream to make sure each step is valuable, capable, available, adequate, flexible, and that all the steps are linked by flow, pull, and leveling? - People: How can the organization insure that every important process has someone responsible for continually evaluating that value stream in terms of business purpose and lean process? How can everyone touching the value stream be actively engaged in operating it correctly and continually improving it? Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles:
Kanban
Visualize the workflow Limit WIP Manage flow Make process policies explicitexplicitImprove collaboratively
Kanban is a method for developing software products and processes with an emphasis on just-in-time delivery while not overloading the software developers. It emphasizes that developers pull work from a queue, and the process, from definition of a task to its delivery to the customer, is displayed for participants to see. People don’t know what you’re doing. If they can’t see it, or they don’t understand what you do, they will think you’re doing nothing. Then they will come over with more new ideas. You need to make your work visible Emphasizes just-in-time delivery Developers pull work from a queue Entire process is displayed for all to see
R1
R2
R3
Prioritized fo
r value
Agile BA Principles
Product Backlog
Now…
Soon…
A little later…
A lot later…Prioritized fo
r value
OK, so let’s see how all those concepts fit together for business analysis. The business has to prioritize what they want. They need to think about what will offer the most value to the organization (or its customers, shareholders, etc.) and therefore what needs to be done first. The product backlog needs to be constantly groomed as priorities shift. We need to elicit, clarify and validate requirements “just in time” for this sprint or for the next sprint. We work as a team; it’s a “partnership relationship” between the sponsor (business stakeholder), the customer (represented by the product owner) and the implementation team.
In order to <accomplish something of value to me or to my organization>.
A lot of Agile approaches start by capturing requirements in the form of user stories, often written on index cards or something similar. User stories short descriptions of functionality described from the perspective of a user; they tell us what the user needs to do and why (i.e. what value does it bring?). Mike Cohn, in his book User Stories Applied, calls user stories “a promise for a conversation.” Here’s how he thinks of it… Card – stories are traditionally written on notecards, and these cards can be annotated with extra details. The cards are used for planning and as a reminder or placeholder for a conversation. Conversation – details behind the story come out through conversations with the Product Owner. Confirmation – tests and/or acceptance criteria that define when the story is “done.”
“User Stories are the new Requirements”
As a conference participant…
I need to register online…
In order to register quickly and cut down
Functional
Non-functional?• DataIn order to register quickly and cut down
on paperwork.• Data• Rules• Qualities• Interfaces• Constraints
Conversation So, if a card is a promise to have a conversation, then what is the conversation about? The conversation is typically between a business analyst and the product owner, and the purpose of the conversation is to elicit additional requirements about the function described on the card. For example, I attend a lot of conferences and here’s an example of some functionality that would really help me. We can see from this statement that I need to register online. That’s a good start, but what else do we need to know about this capability? There are a lot of non-functional requirements that are associated with this statement, but are not here. Here are some questions we might ask the product owner: Data: What information needs to be collected to allow a participant to register? Rules: Can the participant pay online as part of the registration process? Must they pay the full amount? What if they cancel; can they get a refund later? Qualities: Where does this information need to be collected/delivered? Web-based app? Kiosk at the conference? How many registrations will there be? What security/privacy needs to be in place? Interfaces: Will we provide the participant information to the conference vendors? Does the user need to be sent an acknowledgment?
“User Stories are the new Requirements”
As a conference participant…
I need to register online…
In order to register quickly and cut down
Acceptance criteria?
In order to register quickly and cut down on paperwork.
Confirmation Acceptance criteria define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. For the above example, the acceptance criteria could include: A participant cannot submit a form without completing all the mandatory fields Information from the form is stored in the registration database Protection against spam is working Payment can be made via credit card Test Visa, MasterCard, Discover and American Express (pass) Test Discover (fail) Test with good, bad or missing SID codes Test with expired cards An acknowledgment email is sent to the participant after submitting the form. As you can see, the acceptance criteria are written in simple language, just like the user story. When the development team has finished working on the user story they demonstrate the functionality to the product owner, showing how each criterion is satisfied. Including acceptance criteria as part of your user stories has several benefits: they get the team to think through how a feature or piece of functionality will work from the user’s perspective they remove ambiguity from requirements they form the tests that will confirm that a feature or piece of functionality is working and complete.
R1
R2
R3
Prioritized fo
r value
Product Backlog
Now…
Soon…
A little later…
A lot later…Prioritized fo
r value
So now let’s fit everything together: Requirements are captured as user stories and prioritized into the product backlog by the product owner. The highest priority items are developed in the next sprint. User stories need to be fully developed with other requirements, acceptance criteria and possibly test scenarios before they can be developed. Anything missing from these stories become blocks for the development team and could slow them down or even stop them. It’s a partnership relationship—we are consensus-driven, self-empowering (and empowered), motivated by trust, respect and courage, and we continuously improve. The business analyst is part of that partnership in one or more ways: The BA may be part of the team. (Careful—how is “team” defined? If it’s “developers,” then having a BA as part of that team may degrade velocity as the BA is counted as a team member but doesn’t contribute code [where velocity = code/developers].) The BA may take the place of the product owner as “the voice of the customer.” This is close to a traditional BA role. The BA may be off on their own, outside of the typical Scrum structure and working on behalf of the product owner to talk with other business stakeholders.
What Skills Does the BA Need?
Working software Comprehensive documentation
Processes and tools
Customer collaboration
Following a plan
Contract negotiation
Individuals and interactions
Responding to change
over
over
over
over
Lightweight documentation; user stories, models, and prototypesCard, conversation and confirmation; acceptance criteria and testsThink goal, not role (or title); collaboration and systems thinkingRetrospective; continuous improvement
Lightweight documentation; user stories, models, and prototypes Without a lot of heavy documentation, we depend more on user stories (remember the back of the card!), a lot of quick-and-dirty models, and prototypes to confirm Card, conversation and confirmation Start with the card (user story) Have conversations to flush out the remaining requirements Acceptance criteria, test scenarios and prototypes to confirm Think goal, not role (or title) Agile works best with self-organizing, cross-functional teams Retrospective; continuous improvement If you’re not doing retrospectives you aren’t doing Agile It’s all about “inspect and adapt”
