On Tuesday, August 7, 2012 Kris Ashton, presented the web seminar “Business Analysis in Agile Projects.” In this one-hour web seminar, Kris provided participants with an overview and understanding of the role of the BA, the tools and techniques best suited to Agile projects, and the timing for performing key tasks and events during the project.

Business analysis is an essential function in every project, whether it be traditional or Agile. Effective analysis performed by competent business analysts can make the difference between successful and challenged or failed projects–even Agile projects. At the end of this web seminar, attendees had an understanding of the BA role and the best tools and practices a Business Analyst should use.

Recording
Listen to a recording of this web seminar in its entirety by clicking View Event Recordings (at the top right).

Q&A

Note: Answers are the sole opinion of the webinar instructor and in no way reflect any specific approach or implementation of Agile.

1. I’ve successfully used User Stories to gather requirements in a more traditional SDLC/corporate environment. What other Agile tools/approaches might you recommend that might promote the Agile methodology in an otherwise traditional development shop?Agile is a completely different paradigm. While it’s possible to adapt tools/approaches from traditional to agile approaches, to really promote agile in an organization requires that organization’s leadership to be willing to adopt it entirely. Otherwise, agile doesn’t necessarily introduce any new requirements-elicitation tools or techniques aside from user stories.
2. Can you use KANBAN when doing SCRUM? Or are they mutually exclusive?Kanban (“signboard” or “billboard” from the original Japanese word) is a philosophy for limiting work in progress by having developers pull from a queue of work instead of being assigned work. It’s really about how developers manage their time and work commitments during a sprint. It can be used with Scrum (and often is). The one thing that I see mostly taken from Kanban is the idea of the signboard as a way to visually indicate the work on the project.
3. Is the use of Kanban increasing, decreasing or staying the same?I haven’t seen any statistics on that. Again, many people/teams are using a bit of Kanban with the boards they post but they may not realize that is a part of Kanban.
4. Since we do not look at anything which needs to be fulfilled “a lot later,” does that principle of agile result in re-work. Is there data available to prove this?I haven’t seen any statistics to indicate how much or how little re-work results from the long view I described. The idea is to do completely and well what’s in the current sprint (remember, we don’t demonstrate software with defects at the sprint review). I would guess that re-work associated with missing functionality would decrease as we simply don’t know what that functionality is at the moment. Remember also that agile promotes “embrace change” because we know that is going to happen regardless.
   
   
5. With user stories, our BAs author them. Is that wrong? The SMEs should be authoring them.There is a lot of discussion about who is the “right” person/party to write user stories. I agree with you that the SMEs should author the stories but sometimes they don’t know how (easily fixed with story workshops and instruction) or more likely, they say they can’t because they don’t know what they want. I don’t mind BAs writing user stories, in fact I do it all the time on my projects, because I can control the content and quality that way. In the end it doesn’t really matter as long as you are satisfied with the result and the stories are reflective of the needed conversations.
6. Do you have any tips for getting your PO to rank the backlog? Ours prioritize, but we have 100+ high priorities!! With many SMEs/stakeholders, the PO is hesitant to rank.There are many techniques to prioritize a product backlog. One I particularly like when faced with a situation such as yours is multi-voting. That’s where you conduct a workshop in which you give each participant some number of stickers, put the stories up on the wall, and have them assign stickers to the stories. For example, if you give them 10 stickers and say “you can put all 10 on one story, 3 on one story and 7 on another, etc.” and then see how they assign them. Remember that whatever technique you use, be sure to check against the business objectives the project is intended to deliver.
7. How much should stories be broken down? I’ve heard <13 points but this is too hard if, say, you have a 30 point story which really s/b delivered all in the same sprint.
   
   I haven’t seen any numbers on this but I’d say that if you can’t break a story down any smaller, and it’s still 30 points and must be done in one sprint, then that’s what you have to do.
8. For AC do you flesh out all alternate scenarios? We try to do 80% but testers get mad that we don’t do all.
   
   I try to describe every extension scenario that I (or the business SMEs) can think of. I think testers have standard scenarios they look for but I tell them everything I can think of—I just don’t want to miss anything. Yes, it takes longer but in the end it’s better because if the alternate scenario is something the business knows about and does then it should be described in business language like every other requirement, user story or use case.
9. Does the test criteria (as requirements) have a specific or most-used format? Developers like detail….I haven’t seen any “universal” format for acceptance criteria. I think you just tell developers in as much detail as you know what they should test for. You can specify particular inputs and expected results for user stories, for example. I think it’s best to work with your specific developers and see what they are looking for as different developers want different things.

10. Is it normal to do the requirements definition before the developers begin coding in a sprint?As a BA I like to plan for 20% of my time to be available to clarify any questions that developers have about items they are working on in the current sprint. The remaining time is spent developing the detailed requirements they will need for the items in the next, upcoming sprint(s). It’s a sign of my skill as a BA that I don’t spend too much time clarifying things they are working on now—that just slows them down. I should have everything pretty well developed before they got it. (Of course, that’s true for all projects, not just agile!)
11. If the focus is lightweight documentation, where/how do we document the details (non-functional requirements, acceptance criteria, etc.) to ensure those decisions can be referred to for development and testing?
    
    If there’s a way to describe requirements with lightweight models (process flows, data flows, data structures, etc.) I’ll do it that way. Some requirements, like business rules and quality attributes, can’t really be modeled and must just be stated somewhere like a requirements repository (hopefully shared by the entire project team and under version control). I think this on one of the big misconceptions—we need to keep these non-functional requirements somewhere!
12. What percentage of the BA’s contribution to a release should be done before and during RELEASE PLANNING, vs. later?
    
    I haven’t seen any numbers on the percentage allocated to this but in general, this is part of what I call scope planning and is an activity I feel is best led by a BA or PM and in which the business’ key stakeholders decide what features/functions/capabilities to include in what release.
13. Exactly where does the Project Manager fit into the Agile process?|An agile project is still a project, and in my opinion still needs a Project Manager just like any other project would. Recall the role/responsibilities of a Project Manager are more or less outside of the approach or methodology that is used on the project (although he/she must be familiar with the approach in order to lead the project effectively). Remember: the Project Manager is not a BA, is not a Product Owner, is not a Scrum Master, or any other role.