ASPE RESOURCE SERIES The Business Analyst Role in Agile Projects and How To Do It Prepared for ASPE-SDLC by Rob Snowden The skills we teach drive real project success.
The Business Analyst Role in Agile Projects and How To Do It Agile, in the strictest sense, only has 3 roles The Product Owner, the Scrum Master, and the delivery team. There s no specific role for the BA, but there s also no specific role for the tester, architect, data administrator, and others. All team members do what needs to be done. So the BA needs to ask, What does the team accomplish? and Which things am I best able to do? The Choices a BA has: 1. Product Owner The Product Owner needs significant domain and product knowledge to guide the decisions of what to develop. So, if the BA comes from the business or is otherwise very knowledgeable, this is a good fit. On the other hand, there are so many things that a Product Owner is responsible for in an Agile project, for which the BA can significantly assist. Consider the BA assisting the Product Owner with: a. Leading product discovery activities. b. Creating and communicating the product roadmap to various stakeholders. c. Pruning and grooming the product backlog. d. Assisting in the planning of various workshops. e. Specifying the acceptance criteria for backlog items. f. Creating user stories, then leading or co- leading the fleshing out of the requirements. A workable approach is for the Product Owner to work closely with the BA to accomplish these things. 2. Scrum Master The facilitation and coordination skills required means, in a certain sense, that specific business knowledge isn t necessary, but strong people, facilitation, and coordination skills are. 3. Development team The team is a mixture of people with various skills testing, coding, analysis, etc. People on the team do what needs to be done. So we re back to number 1 above. Taking a just- in- time approach, the BA could be working about 2 sprints ahead on requirements for a future sprint, while responding to questions on the current sprint. The BA as Liaison between Product Owner and the team and a process to do it If the Product Owner is customer facing, the Product Owner could be the source of requirements to the BA. On the other hand, the BA may be more naturally inclined to conduct elicitation sessions with the Product Owner and others to extract requirements. The BA ensures that all requirements are elicited and are translated by the Product Owner, with the BA, into user stories then into more fully developed requirements. The BA would also work with the Product Owner/other team members to prioritize the user stories by business value. Once prioritized, the user stories would be sequenced for a particular sprint and additional user stories would be identified within the sequenced user stories and further requirements development would occur. The BA would be working on requirements for a future sprint that is 2 2013 ASPE all rights reserved Page 1
sprints out (Sprint +2) so that the requirements would be completed prior to the sprint beginning. For example: 1. Brainstorm what the customers to do Imagine the Roadrunner/Coyote cartoon in which the Coyote, tired of obtaining bogus traps from ACME, wants a system in which traps from various vendors can be ordered and paid for electronically. Working with the Product Owner and representatives of the coyote community, things that coyotes do are brainstormed in verb/noun format. 1. Order traps 2. Record success rates 3. ID best location 4. Delete vendors 5. Maintain vendors 6. Evaluate success of coyotes 7. Process invoices 8. Predict best locations 9. Predict best traps 10. Evaluate vendors 11. Generate electronic payments 12. Pay coyote incentive payments 2. ID user stories based on the brainstormed list Of these brainstormed items, a subset/combined/condensed version is translated into user stories by the Product Owner/BA and written on cards and placed in the backlog. A. As a coyote I record the success rates of traps so I can select the most effective ones to reorder B. As a coyote, I determine the best location for traps to maximize the chances of catching C. As a coyote, I need the ability to predict which traps and locations will guarantee successful capture of road runners D. As a coyote, I to maintain E. As a coyote, I to process invoices so I can pay vendors F. As a coyote I order traps from viable vendors so I can capture G. As a coyote, I coyotes by their success rates of capturing roadrunners so I can pay them earned incentive payments. H. As a coyote, I delete vendors that are not viable to remove unneeded 2013 ASPE all rights reserved Page 2
3. Prioritize users stories by business value The BA would be very involved in helping the Product Owner prioritize the user stories. It s the Project Owner s responsibility but the BA would work closely to help determine those which provide the most value for a particular sprint. In the example below, the eight user stories were prioritized using the MoSCoW process to begin the Story Mapping process. Through this simple process, the eight stories, in this case, are reduced to 3 user stories for the upcoming sprint. Mo S Co W Must Have absolutely critical Should Have If possible Could Have Nice to have Won t Have (for now at least) E. As a coyote, I to process invoices so I can pay vendors F. As a coyote I order traps from viable vendors so I can capture D. As a coyote, I to maintain A. As a coyote I record the success rates of traps so I can select the most effective ones to reorder B. As a coyote, I determine the best location for traps to maximize the chances of catching H. As a coyote, I delete vendors that are not viable to remove unneeded G. As a coyote, I coyotes by their success rates of capturing roadrunners so I can pay them earned incentive payments. C. As a coyote, I need the ability to predict which traps and locations will guarantee successful capture of road runners 2013 ASPE all rights reserved Page 3
4. Working with the Product Owner, sequence highest prioritize stories and ID additional user stories The BA, working with the PO, sequences the highest prioritized user stories, then further develops them by identifying additional user stories that support the original stories. D. As a coyote, I to maintain F. As a coyote I order traps from viable vendors so I can capture E. As a coyote, I to process invoices so I can pay vendors 1. As a coyote, I to add vendors so I can 2. As a coyote, I to modify maintain current vendor information. 3. As a coyote I place new trap orders from vendors so I can catch 4. As a coyote I modify/cancel a trap order once placed so I can correct an erroneous trap order before it is filled. 5. As a coyote, I receive an Accts. Payable report so I can approve payments to trap 6. As a coyote, I to generate electronic payments to pay vendors for traps received. 5. BA works with Product Owner/others to flesh out requirements by user story Then, working with the PO, the BA develops use cases and other identifies other requirements business rules, quality attributes, etc. The BA can also make suggestions for the UI. For example, the use case for user story 1, above might be: Use Case: UC- 1 Add Vendor Actor: Coyote Level: User Goal Preconditions: Coyote is logged on and main menu is displayed 2013 ASPE all rights reserved Page 4
Post Condition: Vendor added Trigger: Coyote selects Add Vendor from main menu Main success scenario: 1. System displays Add Vendor screen. 2. Coyote keys Vendor data and submits (See section 4.5 for data, edits, format, etc.) 3. System UC- 2 Validates Vendor Data. 4. Coyote verifies data vendor data and approves. Extensions: *.a Coyote does not respond to a system prompt in 5 minutes 1. System displays 2 minute warning *.b Coyote fails to respond after a 2 minute warning 1. System logs Coyote off 3a System identifies data that does not pass edits (See Sub Use Case UC- 2 for details) 1. System highlights erroneous data with error message (See section 4.5.1 for error messages) 2. Coyote corrects data and submits 3. System revalidates data 4a Coyotes choses to not approve data 1. System returns coyote to step 2, displaying previously submitted data 2. Coyote makes corrections 6. The BA and Product Owner review requirements with the team at the beginning of the new sprint When the new sprint is ready to start, the BA and Product Owner have the requirements ready. As they clarify requirements for the current sprint, they continue working on sprint +2 meaning a sprint that is 2 sprints in the future. 2013 ASPE all rights reserved Page 5