The Role of the BA in Agile Software Development
Download as PPTX, PDF3 likes1,057 views
The document discusses the role of business analysts (BAs) in agile software development, emphasizing their responsibilities in defining product requirements and aligning solutions with stakeholder needs. It outlines the definitions of agile and scrum methodologies, the roles of scrum team members, and how BAs interact with product owners. Additionally, it highlights the importance of user stories and techniques for effective backlog prioritization in agile environments.
The Role of the BA in Agile Software Development
- 1. The role of the BA in Agile Software Development IIBA Central Indiana Chapter - Jan 2016
- 2. Introduction In which, we discuss what is Agile, what is Scrum, and where Business Analyst fits in. I’ve been a Developer, a Project Manager, a Product Owner, a Business Analyst, a Development Team Manager and a Consultant. I have a special interest in Lean and Agile application development. John Durgin, CBAP, MBA, CSM, CSPO
- 4. A formal definition Agile is a collection of values and principles expressed in the Agile Manifesto for Software Development. Scrum is a development framework based on empirical process control wherein cross functional, self- organizing teams deliver working software every 30 days or less. Sprint RetrospectiveModify
- 5. The Agile Values Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. http://www.agilemanifesto.org/
- 6. Scrum Roles Scrum Master -The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. Product Owner -The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner. Development Team - The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.
- 8. Project Management - The Iron Triangle Time Scope Resources: People, $$ Quality
- 9. Project Constraints Traditional: Software Projects Scope and Time are fixed. The job of the Project Manager is to manage resources and budget. Scrum: Product Development Time and Resources are fixed The job of the Product Owner is to manage scope.
- 10. ? Questions
- 11. The Business Analyst vs. Product Owner The BA defines and manages the product requirements: the “what” The Product Owner defines and manages scope: also the “what”
- 12. What is Business Analysis? Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysts are responsible for discovering, synthesizing, and analyzing information from a variety of sources within an enterprise, including tools, processes, documentation, and stakeholders. The business analyst is responsible for eliciting the actual needs of stakeholders—which frequently involves investigating and clarifying their expressed desires—in order to determine underlying issues and causes. None of this changes in Agile
- 13. What do they do? Business analysts play a role in aligning the designed and delivered solutions with the needs of stakeholders. The activities that business analysts perform include: • understanding enterprise problems and goals, • analyzing needs and solutions, • devising strategies, • driving change • facilitating stakeholder collaboration. None of this changes in Agile
- 14. Business Analyst Roles in Agile From the BABOK Agile Extension: ● The analyst might act as the product owner/customer representative where they are empowered by the business to make decisions on product features and priority. ● The analyst could act as a surrogate product owner, in situations where the business product owner is not available. ● The analyst might act as the second in command to a business product owner with limited availability. The Agile Extension lists numerous other roles, all peripheral to, and in support of the product owner.
- 15. Product Owner Responsibilities and Skills The Product Owner must... Skills required Understand the Business Need Facilitation, Elicitation, Analysis, Enterprise Analysis, Strategy, Business Value, Relationship Building Create a Vision Analysis, Consensus Building, Clarity Develop a Roadmap Planning, Alignment (with strategy, goals), release planning Backlog Refinement Prioritizing, functional decomposition Challenging and Motivating the Team Leadership, Knowledgable, Available, Integrity, Building Trust Make Decisions Take Initiative, Domain Expert, Relationship Building with Stakeholders, Empowered Define Acceptance Criteria Analysis, Clarity, SME Single Wringable Neck Take Ownership, Accountable
- 16. Desirable Characteristics of a PO ● A Visionary and a Doer ● Leader and Team Player ● Communicator and Negotiator ● Empowered and Committed ● Available and Qualified ● Spends half the time with users, business leaders, and IT leaders. ● Spends the other half working closely with “the development team” clarifying specifications. As a BA, how are doing in these areas?
- 17. A Successful Product Owner... ● Is always thinking of business value. ● Encourages and Leads the Development team by Communicating Vision ● BUT, is not the sole source of that vision. It must be collaboratively developed and widely shared. ● Clarifies business/user needs to development teams so that uncertainty is removed and developer velocity is maximized ● Prioritize, Prioritize, Prioritize How are your skills?
- 18. On any given non-trivial project the BA skills and availability of the Product Owner will be critical to project success. If the PO is not so equipped, a BA can help make a project successful
- 19. ? Questions
- 20. The Agile Business Analyst It’s a skillset, not a role or a title Yah, but what do you do?
- 21. Business Planning Level Roles Involved Result Strategic C-Level Management Business Plan Functional Alignment CIO, CTO, Business Leadership IT Roadmap Solution Alignment Functional Directors Product Owner, Business Analyst Product Roadmap Solution Definition Product Owner, BA, Stakeholders Product Backlog Sprint Planning Product Owner, BA, Dev Team Sprint Backlog
- 22. The Business Analysis Process (traditional) Problem or Opportunity Identified Functional Decomposition Detailed Requirements Solution Selection Roadmap to Solution Prioritization In Scrum, functional decomp results in “Stories”, which get prioritized
- 23. BA Techniques - User Stories Note: The concept of user stories is not defined by Scrum. It comes from XP. ● Card, Conversation, Confirmation (Ron Jeffries, Extreme Programming) ○ As a <role>, I want to <do>, so that I can <get value> ○ The user can <do something> ● It’s about the goal, not solution attributes ● Story Design - Independent, Negotiable, Valuable, Estimable, Small, Testable No, there is not a 1-to-1 between user stories and functional requirements.
- 24. How to Build a MVP stories not Independent Independent minimum viable product
- 25. Good User Stories ❖ Negotiable: ➢ The “story” is a reminder to have a discussion ➢ stuff may change, don’t write too much ❖ Valuable: ➢ Stories need to reflect business goals ➢ The PO is accountable for determining value and adding to the product backlog ➢ Learn about story mapping ( that is whole talk in itself) Independent Negotiable Valuable Estimable Small Testable
- 26. Good User Stories ❖ Estimable: ➢ If the team is having difficulty, likely the story is too large or complex or calls for technology that the team has no expertise in ❖ Small: ➢ Story Slicing ➢ vertical slice = independent ➢ adding details = acceptance criteria ❖ Testable: ➢ if you’ve got some good ACs ➢ make sure details add definition, not scope Independent Negotiable Valuable Estimable Small Testable
- 27. Prioritizing the Product Backlog
- 28. Acceptance Criteria Back of the “card”, capture detail (Confirmation) Different takes on how to use acceptance criteria 1. Try it with <different data> 2. I can <variations on the function> 3. define parameters of the function 4. define when the story is complete 5. function is working as expected AC are NOT tests. They can point to the need for certain tests.
- 29. ? Questions
- 30. "There are lots of people who believe their job is collecting and communicating requirements. But it's not. The truth is, your job is to change the world. Every great idea you turn into a product solution changes the world in some small, or not so small, way for the people that use it." - Jeff Patton, author of “User Story Mapping”
- 31. Follow-Up Reading Some books I highly recommend: User Story Mapping - Jeff Patton Agile Product Management with Scrum - Roman Pichler User Stories Applied - Mike Cohn
- 32. ? Retrospective. What went well? What did not? WHY
- 33. Thanks! Contact me: LinkedIn: John R. Durgin Twitter: @moshuptrail eMail: john.r.durgin@gmail.com
- 34. The Marshmallow Challenge an exercise in agile development tools: 1 marshmallow, 12 sticks of spaghetti, and a 3’ length of painter’s tape The object of the game is to build the tallest freestanding structure of spaghetti and place the marshmallow on top. Teams: 3-4 people each Team formation, roles and responsibilities: 1 minute Then 14 minutes to build a solution