Elizabeth Larson, PMP, CBAP, CSM, CEO and Co-Principal of Watermark Learning (There have been many articles lately about the role of the BA on Agile projects. Some postulate that the BA role is closest to the product owner. After all, it is often suggested, they reside with and represent the business. They are in the best position to be the final voice when defining and prioritizing requirements. Others believe that the key role for the BA on Agile projects relates to testing. Since they define the requirements, they should complete the appropriate testing processes to ensure the final solution meets the requirements. I believe that neither of these is a business analyst role. That's not to say that someone with the title of BA cannot play other roles as well. It's just that when they are playing these other roles, they are not doing business analysis work.
BA as Product Owner.
The role of the product owner is essentially that of the business subject matter expert (SME). Their main accountability on the project is to articulate the vision and define and prioritize product requirements. Their role, as the sponsor's key delegate, is to make business decisions. The BA has accountability to both the business and the project. On the one hand BAs need to ensure that the end product or service meets the business objectives, and that the requirements are defined completely and correctly. However, they also need to ensure that the end product or service meets the project objectives and that it is delivered within the project constraints. Finally and maybe most importantly, BAs are not decision-makers. They are facilitators, consultants and, hopefully, trusted advisors.
BAs as Testers.
Testing on Agile projects is an essential role. While theoretically the delivery team wears multiple hats, one of which would be that of tester, practically speaking I have seen more instances where outside testers fulfill this role. With the wide-spread use of automated testing tools on many agile projects, it is helpful to pay attention to testing on its own with its own resource(s) devoted to it. It seems to me that, as with any approach, separating both business analysis and testing from development work, makes a great deal of sense.
BAs as BAs.
So where do BAs most effectively fit into an agile project. BAs are most effective doing BA work, but the work needs to be done just-in-time.[1] Here are just a few ways the BA can support the agile project:
- Help the sponsor and product owner define and articulate the business problem and product vision
- Elicit requirements using a variety of techniques, including facilitating cross-functional requirements workshops
- Assist the product owner in developing user stories and the associated acceptance criteria so the delivery team will know when they're done. These criteria need to be more complete than, for example, "the order has been placed." I have found that creating specific criterion tends to be difficult for product owners.
- Trace user stories to business objectives and the product vision and throughout the sprint to ensure it's actually been delivered as imagined.
- Model the "as-is" and "to-be" business processes.
- Model the expected system interactions, particularly when software is being developed.
- Look for gaps in data requirements between what is in place and what is needed. Model the data requirements or work with the appropriate people to ensure that the data will support the new solution.
- Create mock-ups of the new user interfaces.
- Support the product owner by discussing business and technical impacts of and dependencies related to priority decisions.
- Assess how ready the organization is to accept the change.
"Grooming" the Backlog.
So how can BA do all the things BAs do so well without preventing the team from delivering an increment in short time frames, such as 2-4 weeks? By ensuring requirements are defined completely and correctly before each sprint begins. The BA can work with the product owner and other business and technical SMES as the delivery team completes each sprint. However, the BA is working on requirements for the upcoming sprint, rather than the current sprint.
While many organizations use the term "agile" to mean doing things in a quick and dirty way without adding a layer of business analysis bureaucracy, others have considered the consequences of omitting the role of the BA and are now recognizing the vital role BAs can play.
[1] In the 2010 survey, The State of Business Analysis in Agile IT Practices, participants indicate that "requirements for Agile projects should be immediately consumable by IT project teams. 72% of companies surveyed indicated that requirements should consist of process flows (or visual use cases) or visual story boards in lieu of only textual lists and paragraphs. Requirements that include visual assets (such as business process diagrams, use cases, user interface mock-ups, and data relationships) require less interpretation from project teams and are more accurately leveraged for project direction" (Executive summary p. 4 http://www.requirements.net/2010/06/30/now-available-the-state-of-business-analysis-in-agile-it-projects-survey-report/)
Don't forget to leave your comments below
Subscribe to this comment's feed
written by kmcdanie, July 13, 2010
-
- +0
-
-
written by dwright, July 13, 2010
Bravo! The more people who say this, the more impact we can have on organizations' thinking about Business Analysts, especially in job postings. (The other sticking point is domain experience, for another article perhaps.)
"However, the BA is working on requirements for the upcoming sprint, rather than the current sprint."
I call this a "cascade", generate enough content for a team to start a cycle/sprint, and then keep one sprint ahead of the team to ensure there is no lost time or un-needed re-work.
-
- +0
-
-
written by SimonTheBA, July 13, 2010
I admit that it makes for a slightly more stressful and busy experience, but I don't see how it would be practical for this company to hire two people to do analsysi and testing.
-
- +1
-
-
written by dwright, July 13, 2010
I have not worked in such a situation, especially a start-up. which I hear can be exhilarating and exhausting at the same time. The interesting question is: what happens when the company grows large enough that it can indeed bring on more people? Will it start to specialize roles more? I.e. if you had more people now, how would you use them? Because assuming growth continues, eventually you will.
-
- +0
-
-
written by SimonTheBA, July 14, 2010
Which is where the 2 developers and I come in...
We are actually increasing our staff shortly - another developer, to increase the project's output.
Also, the IT manager is already talking about having a permanent BA role in the department (I'm here only for the duration of the replacement project). I doubt that a tester is even on the horizon, though - any person filling the BA role would automatically double up as a tester. Hiring a separate tester would be a few more years down the track, I believe. The company would have to become a LOT bigger to justify that!
-
- +0
-
-
written by SimonTheBA, July 14, 2010
We're recording requirements using the electronic equivalent of story cards - a sentence or two to describe the requirement. At the start of each sprint (which we call "iteration"), we then decide the stories to work on for that sprint. I therefore don't know which stories to "flesh out" until the sprint has started... How do other BAs know in advance of a sprint which stories need to be defined?
-
- +0
-
-
written by KBanjo, July 14, 2010
-
- +0
-
-
written by lynn.shrewsbury, July 14, 2010
-
- +0
-
-
written by consultvanand, July 15, 2010
Nice article and good topic to discuss.
Currently, I work with a application maintenance and support project under whitebox model. My role as a BA is to provide process support and qa checker activites. I did not get opportunites to talk with client and play a passive role. The team follows srcum method which is been implemented by client. My role is restricted only to internal level and not exposed to clients. How can I still claim that I am a BA in such projects and how can I put the same in my profile? I would request some members also to provide their thoughts which will be useful.
Cheers,
Anand
-
- +0
-
-
written by dwright, July 16, 2010
1) How do you decide what stories go into a sprint?
2) How long does it take to flesh out a story? (and how do you do that?)
3) Can you identify the stories with enough lead time to have them done when the team needs them? If not, why not?
dww
-
- +0
-
-
written by elizabeth.larson, July 18, 2010
It’s important to break large user stories into smaller, well-defined ones. When we’re beginning it’s helpful to “size” each user story. You can use broad-brush estimates, such as huge, large, average, small, tiny, or whatever terms you’d like. Some people like clothing sizes ranging from extra large to extra small. The important thing is that in the beginning of the project or release some user stories will be well-defined. Usually these are small. Others are undefined and are often called “epics.” These undefined user stories have to be broken into smaller ones prior to building them in a sprint.
The more defined user stories are put into closer sprints. Epics have lower priority and are developed later. As the user stories are prioritized time must be spent to make sure they are well-defined. As the product owner works with the delivery team in the current sprint, the BA can clarify the requirements. How long it takes to go through the product backlog and clarify the user stories depends on the project. There are no guidelines. We know that if we have a user story that says, for example, “as an order taker I want to place an order so that I can provide customer service to phone customers” is going to take some time to figure out. What does “place an order” mean? It’s too vague to be useful to the delivery team. Better is “as an order taker I want to check the inventory status of each item so I can provide customer service to phone customers.” Although the story still needs further definition, it is much smaller and easier to understand than the first. It really depends on your application, though, how long it will take to get the items in the product backlog to a point where they belong in a sprint.
-
- +0
-
-
written by SimonTheBA, July 27, 2010
1) The project team (Project Manager & 2 developers & me & 1 User Rep) get together on the first day of each iteration to agree what will be worked on in that iteration.
2) Fleshing out a story can take anything from half-an-hour to a couple of days, with most taking only a few hours. The developers now have a fairly good domain knowledge, so there's not a lot of fleshing out to do, and I've already done most of the background work on the business processes, so I usually don't have to do much investigation once a story has been chosen to work on.
3) I could sit here now and flesh out every story in our backlog, months and months before they're ever going to be worked on - but isn't that against the Agile philosophy of "just in time requirements over just in case requirements" (a phrase I picked up recently which I love!)? Aren't we supposed to only develop the stories that are being worked on now, or in the very near future? However, I can't narrow down my focus because I don't know which stories are in the next iteration until we start that iteration...
-
- +0
-
-
written by SimonTheBA, July 27, 2010
Thanks very much for your reply.
Most of the stories are already "bite-size chunks"; there are some epics but, as you say, they're lower priority items for later development.
The "fleshing out" I'm speaking of is more related to specific details about how the task/feature will operate. In your example, it's more about things like:
- What is meant by "inventory status"?
- How do we identify an item?
- How will the order taker see the inventory status? Is this a new screen, or part of an existing one? What information do they need? Graphic or textual?
- What method will the order taker use to choose the item they're interested in?
... and so on.
These things aren't covered by a one-line user story - and, from what I understand, shouldn't be. So, when the story is selected for development, these are the things I'm running around trying to define before the developers get to that story - which may be tomorrow or, at the latest, next week (2-week iterations).
-
- +0
-
-
written by dwright, July 30, 2010
"The project team (Project Manager & 2 developers & me & 1 User Rep) get together on the first day of each iteration to agree what will be worked on in that iteration".
Why can't this happen earlier than the first day? Or be part of the iteration plan, start with one story by fleshing it out?
-
- +0
-
-
written by hkmartin, August 02, 2010
-
- +0
-
-
Click Here to login or create a free account.
