I"m a BA Girl in an Agile World
•Transferir como PPTX, PDF•
1 gostou•273 visualizações
Discussing where business analysts fit into the development team on an agile project, 3 amigos, and communication channels.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a I"m a BA Girl in an Agile World
Semelhante a I"m a BA Girl in an Agile World (20)
Mais de Mindy Bohannon
Mais de Mindy Bohannon (11)
Último
Último (20)
I"m a BA Girl in an Agile World
- 1. excella.com | @excellaco I’m a BA girl In an Agile World By Mindy Bohannon
- 2. excella.com | @excellaco • Data Enthusiast • Industry Explorer • Agile Lover • Forever Learner What Worlds Am I In?
- 3. excella.com | @excellaco DC Software Craftsman User Group (DCSCUG) DC Scrum User Group Games for Agility, Learning, & Engagement (GALE) International Institute of Business Analysis (IIBA) User Experience Professionals Association (UXPA DC) Tech Talk DC (Polyglots unite) Agile Defense Proponents Team (ADAPT) DC Continuous Delivery Group (DCCD) Agile Leadership Network (ALN-DC) DC Women in Agile (DCWIA) DC Business Intelligentsia (DCBI) DevOpsDC Excella with the Community Excella founded or leads local IT organizations and Meetups. Join us for an event! Training Offered: CSM, CSPO, CSPO+BA, Kanban Pro I/II, CSD, and more
- 4. excella.com | @excellaco • Traditional Analysis • Agile & Scrum 101 • Analysis 101 • Agile + Analysis • 3 Amigos • Communication Channels • Roles a BA Performs Today’s Intentions
- 5. excella.com | @excellaco Traditional IT Project Management • Process and tools • Comprehensive documentation • Contract negotiations • Following a plan This is how we control projects….
- 6. excella.com | @excellaco Waterfall Process “I believe in this concept, but the implementation described above is risky and invites failure” – Dr. Winston Royce Managing the Development of Large Software Systems, Winston Royce (1970) Requirements Design Develop Test Deploy
- 7. excella.com | @excellaco Agile and Scrum 101 I’m a BA Girl, in an Agile World Standups so Quick, it’s Fantastic!
- 8. excella.com | @excellaco Agile Manifesto Individuals and interactions over Process and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: That is, while there is value in the items on the right, we value the items on the left more. http://agilemanifesto.org/ products product
- 9. excella.com | @excellaco Agile Software Product Development Principles Customer satisfaction by early & continuous delivery of valuable software Welcome changing requirements, even in late development Deliver working software frequently (weeks > months) Close, daily cooperation between business people & developers Projects built around motivated individuals, who are trusted Face-to-face conversation is the best form of communication (co-location) http://agilemanifesto.org/
- 10. excella.com | @excellaco Agile Software Product Development Principles Working software is the primary measure of progress Sustainable development, maintain a constant pace Continuous attention to technical excellence and design Simplicity—the art of maximizing the amount of work not done - is essential Best architectures, requirements, and designs emerge from self- organizing teams Regularly, the team reflects on how to become more effective, and adjusts accordingly http://agilemanifesto.org/
- 11. excella.com | @excellaco Big Bang = Cannonball • Assumptions • Customer knows what they want • Developers know how to build it • Nothing significant will change © Henrik Kniberg
- 12. excella.com | @excellaco from 2017 VersionOne State of Agile Benefits of Adopting Agile
- 13. excella.com | @excellaco • Assumptions • Customer discovers what they want • Developer discovers how to build it • Things change along the way Agile = Homing Missile © Henrik Kniberg
- 14. excella.com | @excellaco • Product Backlog Refinement – grooming stories • Sprint Planning – what can we deliver with our capacity, generate sprint backlog • Daily Standups – status and collaboration • Sprint Reviews – deliver often, adapt to changes • Retrospectives – continuous improvement, every sprint end Scrum Framework – Meetings
- 15. excella.com | @excellaco The Stacey Diagram • Simple projects don’t need Scrum • The Complicated projects benefits from Scrum to increase certainty and agreement • Scrum returns the biggest process gains in the Complex space • In the Anarchy space, there is high risk regardless of method Ralph Stacey, Strategic Management and Organizational Dynamics Technology Requirements Close to Certainty Far from Certainty Close to Agreement Far from Agreement
- 16. excella.com | @excellaco Analysis 101 I’m a BA Girl, in an Agile World Analysis so slick, it’s Fantastic!
- 17. excella.com | @excellaco • Enables change by defining needs and recommending solutions that deliver value • Defines and validates solutions that meet business needs, goals or objectives Definition of Business Analysis
- 19. excella.com | @excellaco • Independent • Negotiable • Valuable • Estimate-able • Small • Testable INVEST with Good Requirements
- 20. excella.com | @excellaco Analysis in an Agile World I’m a BA Girl, in an Agile World Analysis so Sweet, it’s Fantastic!
- 21. excella.com | @excellaco • Flexible mindset • Continually assessing, adapting, adjusting • Just in Time development Agile Approach to Analysis
- 22. excella.com | @excellaco Analysis at Every Horizon Product Vision RoadmapDay Sprint… … … Plan Day Day Daily Scrum Review Retro Sprint Plan Review Retro Idea Initiation Release Plan Release Release Plan Plan Time
- 23. excella.com | @excellaco Progressive Elaboration Now Later Much Later
- 24. How Analysis Fits with Delivery
- 25. excella.com | @excellaco Agile Analysis Requirement Customer Need Product Backlog Item
- 26. excella.com | @excellaco Product Backlog • User needs and business needs • Ordered list of Product Backlog Items (PBIs) • Features, functions, requirements, enhancements, and fixes • Often written as User Stories • Backlog is emergent - is never complete • Dynamic • Constantly changes to identify product needs • Frequently re-ordered *from Scrum Guide
- 27. excella.com | @excellaco What’s a User Story? • Simple, clear, short description of customer valued functionality • 3 parts: • Written description used for planning • Conversation to flesh out details • Tests to determine completeness • 3Cs - Card, conversation, confirmation • Representation rather than documentation Not Core Scrum
- 28. excella.com | @excellaco • Independent • Negotiable • Valuable • Estimate-able • Small • Testable INVEST with Good Requirements
- 29. excella.com | @excellaco Create Shared Understanding I’m glad we all agree. Credit: User Story Mapping
- 30. excella.com | @excellaco Create Shared Understanding Oh! Credit: User Story Mapping
- 31. excella.com | @excellaco Create Shared Understanding Ah Ha! Credit: User Story Mapping
- 32. excella.com | @excellaco Create Shared Understanding I’m glad we all agree. Credit: User Story Mapping
- 33. excella.com | @excellaco Card - Acceptance Criteria • Help define Done • Manage expectations • Lead to new requirements • Attributes: • Objective • Measurable • Tangible • Floor has a shine • Minimal scratches • Deep color Not Core Scrum
- 34. excella.com | @excellaco Card - Acceptance Criteria • Brown • Maple Rio Grande – 5in • No scratches larger than 1in • No more than 1 scratch per sq foot Not Core Scrum • Help define Done • Manage expectations • Lead to new requirements • Attributes: • Objective • Measurable • Tangible
- 35. excella.com | @excellaco Story => Requirements Spike => Research, Hypotheses Bug => Production Issues Card Types - Stories, Spikes, and Bugs As a <your role / who> I want <objective / what> so that <value / why>
- 36. excella.com | @excellaco Conversation How do I describe what I want? How do I validate that this work is done? How do I code this feature? What are the details of this feature? http://www.flickr.com/photos/improveit/1470706210/in/photostream
- 37. excella.com | @excellaco User Roles • Write story from user’s perspective • Understand the user’s goal for the story • Understand the user’s value from the story • Use human users • Avoid using generic “as a user” or “as a customer”
- 38. excella.com | @excellaco Additional Documentation • The conversation might lead to additional documentation • High level design document • Detailed design document • Specifications document • Requirements traceability matrix • Test plan document • Wireframes • Use cases • Just in time documentation • Just enough documentation
- 39. excella.com | @excellaco Product Backlog Refinement PBI PBI PBI PBI Add Split Reorder Remove High priority to next Sprint Granularity Fine Coarse Product Backlog Reorder
- 40. excella.com | @excellaco Evolution of a Story Definition of Ready Refinement Estimating Create Sprint Backlog Definition of Done
- 41. excella.com | @excellaco • Given < situation > • When < action > • Then < expected result > BDD - Gherkin syntax Credit: George Dinwiddie 2013
- 42. *Pairing Activity* Each group will create a user story with a Value Statement and Given-When-Then or with Acceptance Criteria
- 43. As an online shopper, I want to search for products so that I can view and order them Amazon AC: Given I am on a product page When I enter a search term Then I expect to see a smaller list of options
- 44. As a busy professional person on travel, I want to watch movies while connected or disconnect from the Internet so that I can watch my shows anytime, anywhere Netflix AC • I can watch a movie while connected • I can watch a movie while disconnected • I can watch 2 or more movies while disconnected • I can allocate how many movies I can watch while disconnected
- 45. *Pairing Activity* Each group will create a user story with a Value Statement and Given-When-Then or with Acceptance Criteria
- 46. excella.com | @excellaco 3 Amigos I’m a BA Girl in an Agile World Life is tres-tastic, it’s fantastic!
- 47. excella.com | @excellaco • Consists of Product Owner, Developer, Tester • “Developer” meant “Development Team” • BA is part of the Team Who are the 3 Amigos? Credit: George Dinwiddie 2013
- 48. excella.com | @excellaco Scrum Development Team
- 49. excella.com | @excellaco Scrum Team
- 50. excella.com | @excellaco The Peripheral Team
- 51. excella.com | @excellaco Communication Channels I’m a BA Girl in an Agile World Convos so deep, it’s fantastic!
- 52. excella.com | @excellaco • n (n-1) /2, where n represents the number of people that communicate with each other on a project regularly, including PMs/SMs • 2 people = 2 channels pairing • 3 people = 3 channels an extension of pairing • 4 = 6 3 more with one added • 5 = 10 4 more with one added • 6 = 15 5 more with one added How Many Channels Until it Breaks
- 53. excella.com | @excellaco • The more people on the team, the more people in a meeting, the more voices with fantastic ideas to share • Our philosophy: Not everyone needs to be in every meeting • Each team figures out what works for them How Many Channels Until it Breaks
- 54. excella.com | @excellaco Roles a BA Performs I’m a BA Girl in an Agile World Roles so diverse, it’s Fantastic!
- 55. excella.com | @excellaco • Communication • Facilitation • Prioritization • Work with Stakeholders • Requirements BA Skills
- 56. excella.com | @excellaco • Proxy Product Owner (PO) • User Experience (UX) • Tester (QA) • Dual ScrumMaster (SM) / BA • Data Analyst / System Analyst / Process Analyst Different Roles an Analysts Performs
- 57. excella.com | @excellaco ALL OF US! Who is an Analyst?
- 58. excella.com | @excellaco Closing Circle Now you know why I’m a BA Girl in an Agile World – don’t you want to be one too? What will you take back to use with your team?
Notas do Editor
- We are active in our local community and always looking for new opportunities to connect! Join us at any of the user groups we participate in, or contact us if you know of of another group looking for space or sponsors. Our current list of events and speaking engagements is available on our website.
- Anyone have anything else they were expecting/wanting to discuss? How many of you aren’t sure a BA is welcome on an agile project? How many of you are certain a BA is welcome on a waterfall project? Why is that? Please stop me if you don’t know a term I use – grooming stories?
- Story of Agile Manifesto:
- https://en.wikipedia.org/wiki/Agile_software_development Agile software development principles The Manifesto for Agile Software Development is based on twelve principles:[21] Customer satisfaction by early and continuous delivery of valuable software. Welcome changing requirements, even in late development. Deliver working software frequently (weeks rather than months) Close, daily cooperation between business people and developers Projects are built around motivated individuals, who should be trusted Face-to-face conversation is the best form of communication (co-location) Working software is the primary measure of progress Sustainable development, able to maintain a constant pace Continuous attention to technical excellence and good design Simplicity—the art of maximizing the amount of work not done—is essential Best architectures, requirements, and designs emerge from self-organizing teams Regularly, the team reflects on how to become more effective, and adjusts accordingly ------------------------- Listed are some scenarios, for each scenario, identify if: The team is making decisions guided by Agile principles or The team is making decisions counter to Agile principles If the team is making decisions guided by Agile principles, identify which principles If the team is making decisions counter to Agile principles, identify which principles conflict with the decisions
- ASK: What is your favorite principle? https://en.wikipedia.org/wiki/Agile_software_development Agile software development principles The Manifesto for Agile Software Development is based on twelve principles:[21] Customer satisfaction by early and continuous delivery of valuable software. Welcome changing requirements, even in late development. Deliver working software frequently (weeks rather than months) Close, daily cooperation between business people and developers Projects are built around motivated individuals, who should be trusted Face-to-face conversation is the best form of communication (co-location) Working software is the primary measure of progress Sustainable development, able to maintain a constant pace Continuous attention to technical excellence and good design Simplicity—the art of maximizing the amount of work not done—is essential Best architectures, requirements, and designs emerge from self-organizing teams Regularly, the team reflects on how to become more effective, and adjusts accordingly ------------------------- Listed are some scenarios, for each scenario, identify if: The team is making decisions guided by Agile principles or The team is making decisions counter to Agile principles If the team is making decisions guided by Agile principles, identify which principles If the team is making decisions counter to Agile principles, identify which principles conflict with the decisions
- Say the customer says they want this thing (the target). This model works when the following assumptions are true It is hard to hit this target. And the goal moves.
- 75% accelerate software delivery 64% manage changing priorities 49% improve business/IT alignment
- Beyond why companies adopt agile, other benefits are: 66% Project visibility 61% Team morale
- Planning still happens. We capture the learnings throughout the project
- Many other frameworks and methodologies that can be used as well – Kanban, Lean, eXtreme Programming (XP), as well as Scrum
- Benefiting from Scrum and Agile practices
- Business analysis is understanding the problem and exploring solutions that deliver value Involves finding the real problem, not just expressed desire Business analysis is integral to determining the right thing to build
- Identify the real need not just the expressed want or desire… which is putting the solution before understanding the problem. Spend time on the problem, understanding the problem. 5 Whys technique avoid logical traps discussions based on wrong assumptions the essence of why the problem is really happening. Consequently, you can easily avoid playing the blame game, feeling sorry for yourself other unproductive activities, get straight to finding the source of the problem. If you don’t like the result you’re getting, use 5 Whys to understand not just the behavior, but the systems and beliefs and assumptions to uncover what’s really going on. Example: Why did the lawn look bad?- My dog Coco dog was digging it up. Why was Coco digging it up?- Because she was trying to get at the moles. Why were moles in the yard? Because they like the ready supply of grubs. Why are there grubs in my beautiful yard? They are attracted to the new fertilizer. Why did I switch to a new fertilizer?I thought it would make my yard look better! 5 whys have saved Coco and my yard. I've gone back to my old fertilizer, which it turns out is cheaper anyway.
- ASK: Do you consider one point most important? How does that tie in with what you thought was your favorite agile principle? A good requirement - Focuses on the value and feature to develop – not the solution – as much as possible - Smaller requirements are better - easier to prioritize and manage - see results faster - easier to adjust the roadmap as needed - When the team and product owner share the same mindset, you don’t need ultra-detailed requirements - Helpful to have a “Not Doing” section of notes somewhere, like in Confluence, where the PO and development team can see it. https://agileforall.com/new-to-agile-invest-in-good-user-stories/ Focus on the PBI level. I - Stories should be as independent as possible. N - A story is NOT a contract. A story IS an invitation to a conversation. V - If a story does not have discernible value it should not be done. E - A story has to be able to be estimated or sized so it can be properly prioritized. S - Obviously stories are small chunks of work, but how small should they be? – be able to get to a “done” state in the timeframe set by the team T - how do I know when I’m done with the story? Its testable to that point. Helps with ATDD (acceptance test driven development) Other characteristics from the BABOK not listed above: Unambiguous Clear (concise, terse, simple, precise) Correct Understandable Feasible (realistic, possible) Atomic Necessary Implementation-free (abstract)
- Agile encourages flexibility to respond to change. Just in Time development Comes from manufacturing/logistics practices Stories is available for the team at the right level of detail at the right time.
- Analysis is also done at every level of the project- BABOK’s Agile Extension’s Horizons – Strategy, Initiative, and Delivery Not only done in the context of iterative sprints, its done at high level stages, like planning the roadmap Mid-level states, like planning an upcoming release It’s good to keep mid and high level planning light so a team can more easily pivot plans in response to feedback
- Lays out the initially known and best-understood requirements. The higher the order, the more a Product Backlog item has been considered, and the more consensus exists regarding it and its value. Higher ordered Product Backlog items are clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail;
- Here’s the real difference Build Backlog: - Refinement - We work with the PO and team to develop PBIs that meet the requirements of the PO and the team’s definition of ready; grooming and refinement meetings with everyone; output are stories ready to estimate (but not sized yet) Planning for impending work: REFINEMENT - We work with the team to write clear stories and criteria Spring Planning: do the estimating with PBIs ready to develop During work: - We work with the development team when gaps are found or discover additional work or a blocker to identify and adjust the backlog as needed Output: - We also can do acceptance testing
- From the Scrum Guide
- This is just one way to represent a "Requirement" - and you have the flexibility to continue to evolve the requirement as need and de-prioritize if needed.
- Stories in the backlog must fit the same INVEST criteria to be picked up during a sprint A good requirement - Focuses on the value and feature to develop – not the solution – as much as possible - Smaller requirements are better - easier to prioritize and manage - see results faster - easier to adjust the roadmap as needed - When the team and product owner share the same mindset, you don’t need ultra-detailed requirements - Helpful to have a “Not Doing” section of notes somewhere, like in Confluence, where the PO and development team can see it. https://agileforall.com/new-to-agile-invest-in-good-user-stories/ Focus on the PBI level. I - Stories should be as independent as possible. N - A story is NOT a contract. A story IS an invitation to a conversation. V - If a story does not have discernible value it should not be done. E - A story has to be able to be estimated or sized so it can be properly prioritized. S - Obviously stories are small chunks of work, but how small should they be? – be able to get to a “done” state in the timeframe set by the team T - how do I know when I’m done with the story? Its testable to that point. Helps with ATDD (acceptance test driven development) Other characteristics from the BABOK not listed above: Unambiguous Clear (concise, terse, simple, precise) Correct Understandable Feasible (realistic, possible) Atomic Necessary Implementation-free (abstract)
- Card has the details of the requirements Card, Conversation, Confirmation
- Value Statement is the why we are doing this work (story, spike, bug)
- Conversation gets out the concerns each person on the team needs to consider the story done Leads to Confirmation with the PO and Development team we are building the right thing Card, Conversation, Confirmation
- Card, Conversation, Confirmation
- Product Backlog Refinement is an ongoing activity throughout a Scrum project Keep the Product Backlog ordered Remove or demote items that no longer seem important Add or promote items that arise or become more important Split items into smaller items Merge items into larger items Estimate items
- Refinement Definition of Ready Estimating the Story – Story Points Create Sprint Backlog – stories to work on in that sprint Definition of Done Refinement stays 2 sprints ahead of the current sprint work in 2 week sprint cadence
- BDD is a technique used for developing product. It starts with the intended behavior – GIVEN. Requirement written this way is useful to everyone on the project team. Flexible: can be used manually or for a variety of development tools to automate User centric: focuses on actions and outcomes not design specific Light weight: does not require have documentation but focuses on building the thing right
- Slice by Data Boundaries Example: As customer I want to search for a product by it's product number, so I can quickly find a product that I already know; As customer I want to search for products in a price range, so that the search results are more relevant; As customer I want to search for products by their color, so that the search results are more relevant; As customer I want to search for products in a product group, so that the search results are more relevant;
- Explain activity, provide time, then ask each group to share
- Ask for people to share their stories
- What George meant is it takes 3 voices to have a meaningful team. And a BA can be one of those voices! People take the 3 Amigos too literally and forget to talk about the role others, such as a BA, contributes to a team. George meant it as minimum of 3 people, and include everyone else that can add value. https://scrumandkanban.co.uk/three-amigos/ Behavior Driven Development increases speed of delivery through automation of testing. It leads to better customer collaboration, faster response to change, and quicker delivery of working software. Why would this be important? Thinking as the customer Thinking of intended result for customer Eliminates waste (time, documentation, separate req and test scenarios) by focusing our efforts only on those things that deliver value for customer
- Core Scrum Development team are people creating the product- BA, Developer, Tester
- Scrum Team includes the ScrumMaster and Product Owner
- Other SMEs and Stakeholders with a vested interest and ability to help the project team create a better product
- Pairing is common with Developers in agile – an agile supported methodology for working more efficiently with an improved result 3 (3-1)/2=3*2=6/2=3 4(4-1)/2=6 – double the channels and added 3 more channels 5(5-1)/2=10 – added 4 more channels than the last, from 3 the increase is more than double with only 2 people added 6(6-1)/2=15 – added 5 more than last; from 3 the increase was 5 times more channels than 3 additional people – this could be 1 SM, 3 devs, 1 BA/tester, 1 UX https://sciencing.com/calculate-communication-channels-8015685.html
- MB
- Facilitation - brainstorming, story-boarding/story-telling, interviewing and prototyping Excellent Communication – for all those various communication channels (multiplied if there are multiple POs), conversations within the team, with other IT and business teams, at different stages of the work on the feature (grooming, development, testing, overall) Stakeholder management – understanding all SH, taking the time to connect and engage all SH Prioritization – help the SH prioritize, current project has 8 PMs, of which I have 3 over various work on my team Requirements
- - Yes, a BA is all these things at some point UX: If no UX/UI person then BA works with Developers and PO to come up with a design. Not as good as UX/UI person would do though Testing: Most often, a BA also does testing. Depending on the nature of the work and the skill set of the person, a BA does testing – they wrote the requirements and know what the edge cases could be Dual SM/BA: on small project with small teams this is done Other specialties of analysis: data, system, process Result: Analysts think about the broad focus and implications I’ve always been in IT and on technical projects. I can’t imagine a team that would not want a BA on their team. There is no other person on the project that would want to do what I enjoy doing. Talking with the various POs and SMEs, finds everyone knowledgeable about the feature Proxy Product Owner – frequently as the ideal is a dedicated PO but that’s rare Writing to create requirements and stories, with test criteria. I do like the writing! Creates the process flow of the feature Thinking of the long-term big picture, grooming ahead of sprints development work – developers don’t mind doing grooming but its more likely the BA will be the proactive member of the team to continuously have these conversations, ping the developers who happily will do it too. Stepping in for Scrummasters when needed – I’ve been on a project in a dual SM/BA role – with 4 developers – small team Sometimes the primary tester – first one to think of edge testing Poor substitute for UX when there is no one dedicated to doing that on the team Finally, as BA Coach to other Analysts new to the project and/or team
- SF Everyone on the team is an analyst at some point! We all contribute to making good requirements and AC and testing strategies in stories and hypothesis.