This is a hands-on course on implementing the Business Analysis function on an agile project. Working through a case study, you'll gain a practical understanding of where the Business Analysis function fits into agile and Scrum and the value Business Analysis brings to the team and the business. You'll learn how to use your BA skills to shepherd an initiative from the strategic business level down to the 'weeds' of requirements trawling and analysis while keeping the team focused on business value. By the end of this course, you'll have gained practical experience applying the BA function over the course of an agile project to have a more satisfying and productive engagement with the business, while staging the analysis so that the right questions are asked at the right time.
In this course, you will learn how tperform 'just in time', 'just barely enough' Business Analysis on an agile project in order tincrementally develop a comprehensive understanding of business goals and requirements. As you and your team work through a case study project, you'll gain practical experience in how tleverage the BA function and toolkit thelp teams overcome some of the most vexing issues that confront agile teams today, including: how thelp business owners overcome 'prioritization phobia' by guiding them towards an MVP approach tdevelopment; how ttrack dependencies between requirements and development teams; how and when tunbundle epics intmanageable User Stories; when t'bend' agile principles; how tapply UML 2.0; how tcoordinate development across multiple teams and how tmanage supplementary requirements such as non-functional requirements and constraints. You will alslearn when and how tcreate persistent requirements documentation for communication with non-agile teams and for use after the project is over.
In the arguments over agile versus traditional approaches tsoftware development, Business Analysis (BA) has sometimes been ignored - as the elimination of a formal BA position is sometimes confused with elimination of the practice of business analysis, and a reduced emphasis on formal documentation is confused with the remaining need tperform the analysis behind it. As a result, the product backlog is loaded with items that are noted inconsistently, are difficult treconcile with over-arching business goals and difficult testimate and prioritize. The truth is - agile projects, with their increased emphasis on communication between developers and the business side, depend more heavily than ever on individuals (whatever their job title) whknow how tstructure their conversations with stakeholders for maximum benefit, individuals whare able tpull the right analysis techniques out of their 'back pockets' when they need them.Many companies have concluded they need tfind a way tadopt agile approaches because it guarantees at least minimum functionality in a short period of time, eliminates analysis paralysis, reduces technological risk, and minimizes wasted effort analyzing requirements that may never be implemented due tchanging needs. But as teams have tried timplement agile approaches without people trained in agile Business Analysis, they have experienced the following challenges:
If you have been experiencing any of the above, or if your organization is relatively new tagile, this course will help you address these issues through training that clarifies exactly which business analysis technique or tool temploy based on the scenario, and how tcarry out the BA function sthat business interests are addressed and protected throughout the agile life cycle.
None
2 Days
In the arguments over agile versus traditional approaches tsoftware development, Business Analysis (BA) has sometimes been ignored - as the elimination of a formal BA position is sometimes confused with elimination of the practice of business analysis, and a reduced emphasis on formal documentation is confused with the remaining need tperform the analysis behind it. As a result, the product backlog is loaded with items that are noted inconsistently, are difficult treconcile with over-arching business goals and difficult testimate and prioritize. The truth is - agile projects, with their increased emphasis on communication between developers and the business side, depend more heavily than ever on individuals (whatever their job title) whknow how tstructure their conversations with stakeholders for maximum benefit, individuals whare able tpull the right analysis techniques out of their 'back pockets' when they need them.Many companies have concluded they need tfind a way tadopt agile approaches because it guarantees at least minimum functionality in a short period of time, eliminates analysis paralysis, reduces technological risk, and minimizes wasted effort analyzing requirements that may never be implemented due tchanging needs. But as teams have tried timplement agile approaches without people trained in agile Business Analysis, they have experienced the following challenges:
If you have been experiencing any of the above, or if your organization is relatively new tagile, this course will help you address these issues through training that clarifies exactly which business analysis technique or tool temploy based on the scenario, and how tcarry out the BA function sthat business interests are addressed and protected throughout the agile life cycle.
If you need training for 3 or more people, you should ask us about onsite training. Putting aside the obvious location benefit, content can be customised to better meet your business objectives and more can be covered than in a public classroom. It's a cost effective option.
Submit an enquiry from any page on this site, and let us know you are interested in the requirements box, or simply mention it when we contact you.
ITILv3, RESILIA, PRINCE2, PRINCE2 Agile, AgileSHIFT, MSP, M_o_R, P3M3, P3O, MoP, MoV courses on this page are offered by QA Affiliate of AXELOS Limited. ITIL, RESILIA, PRINCE2, PRINCE2 Agile, AgileSHIFT, MSP, M_o_R, P3M3, P3O,MoP, MoV are registered trademarks of AXELOS Limited. All rights reserved.
