The Role of a BA on a Scrum Team IIBA Presentation 2010


Published on

What is your role as a BA on a Scrum team? How do you fit in? This presentation was given to the IIBA conference in NZ in 2010 by Stephen Reed. Stephen had worked extensively as a BA and moved into using Scrum with multiple teams at a large Insurance company. This experience led to a lot of questions around what the BA should be doing on a Scrum team. This presentation goes some way to listing what worked in the teams Stephen was involved in. The BA role does not change and all the skills of a great BA are necessary still on a great Software Development team, just more focused on being a team member and utilising those skills for the Scrum process of getting working software to the customer with more focus and clarity for the user.

Published in: Business, Technology

The Role of a BA on a Scrum Team IIBA Presentation 2010

  1. 1. Sprint •Agile Sprint •Analysis Sprint •Backlog 1 •Scrum 2 •Stories 3 •End DEMYSTIFYING THE ROLE OF THE BA ON AGILE SOFTWARE DEVELOPMENT PROJECTS (USING SCRUM) Stephen Reed BA and ScrumMaster
  2. 2. Scenario – Sprint 19 • We are in to our 4th release of the software • It is day 9 of our 19th Sprint (2 week long sprints) • The team is feeling under pressure as they have only completed 1 of the 7 stories they committed to in sprint planning. • There is no way everything will be done ready for the review, which is tomorrow.What happened?• What could have caused the team to not meet what they committed to?• What have they learnt?• What could they improve on in next sprint?
  4. 4. WHY HAVE A SPECIAL TERM – AGILE?Agile is an umbrella term that includes various approaches, methods, and techniques that: use short iterations and continuous customer feedbackso that the project team can evolve the customer need (a.k.a. the product). -Mario E. Moreira, 2010 CM ExpertSprint •Agile 1 •Scrum
  5. 5. THERE IS AN AGILE MANIFESTO use short iterations and continuous customer feedback So that we can get working software in front of our customer fast, and then repeat the cycle. Sounds practical and pragmatic – right? Can it be done? Who does it? Do we already do it? Do we want to improve our “value add” to the customer? What’s holding us back?
  6. 6. SOMEONE TRIED TO CATEGORIZE THEM ALLSoftware Engineering Bodies of Knowledge.- SDLC 3.0: Beyond a Tacit Understanding of Agile, Mark Kennaley, 2010
  7. 7. THE ROLE OF THE BUSINESS ANALYST?“Far from de-emphasizing the role,agile methods... actually ask more of business analysts than previous methods… …when agile methods are really applied and not merely talked- about, that is” - Dec 9, 2008 4:33 PM by DN In response to by Shane Haste
  8. 8. AGILE REQUIRES ALL LEVELS… to better share leadership and assume the responsibility that goes with it The team is responsible and accountable for their actions; listen, cooperate, and collaborateAdapting Configuration Management for Agile Teams - Mario E. Moreira, 2010
  10. 10. SCRUM IS ONE OF THE AGILE METHODSIncludes (but not limited to) : Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM), Feature Driven Development (FDD), Agile Unified Process (AUP).Sprint •Agile 1 •Scrum
  12. 12. SCRUM – WHAT PARTS APPLY TO ME Same Principles Apply Does not matter what methodology Focus on the Current Iteration Getting working software in front of the user quickly Your pre-work may remain similar (BC, HLR) But with less detail for all requirements Identify the top priority functionality (the PO does this) Make sure you analyse it enough Be ready to bring top priority into your first sprint
  13. 13. RULE - NO CHANGES DURING A SPRINT Change Plan sprint durations around how long you can commit to keeping change out of the sprint Typically 2 weeks is long enough for most Product Owners What if the “developers” say they want 3 week sprints?
  14. 14. ROLES IN SOFTWARE DEVELOPMENT...“Im not sure defining all these roles help.In my mind there are just two roles. People who want software and people who build it.” - Dec 6, 2008 10:17 AM by PB In response to by Shane Haste
  15. 15. SCRUM – THE PRODUCT OWNER Representing the customer Understand the system – or can find out Define the features of the product Decide on release date and content Be responsible for the profitability of the product (ROI) Prioritize features according to market value Adjust features and priority every iteration, as needed Accept or reject work results
  16. 16. SCRUM - THE TEAM Typically 5-9 people Cross-functional: Analysts, developers, testers, user experience designers, etc. Members should be full-time May be exceptions (e.g., database administrator) Teams are self-organizing Ideally, no titles but rarely a possibility Membership should change only between sprints
  17. 17. WHAT DOES CROSS FUNCTIONAL MEAN? Reality is we all have our own specialty… so live with it. What work needs to be done? analysis development testing architecture, dba, dc Testers can do some analysis etc Analysts can do some testing etc Primary goal is to get working software
  18. 18. IN SCRUM THE TEAM IS… committed, empowered, self-organized They can make the best decisions to move forward… because they are the closest to the challenges and work to be accomplished Empowerment does not mean leadership… Its about having the ability to make the right decisions at the right time and doing it Have discussions, not change requests!
  21. 21. THE ROADMAP – LETS GET CLEAR "What am I supposed to be doing on the team?“ Story Writing with Product Owner Analysis of Product Backlog Items Clarification with PO on Acceptance Criteria (AC) Story prep for Grooming Mocking up User Interfaces (UI) with the PO Clarifying and defining User Experience (UX) criteria with the PO / team. Building Conditions of Satisfaction with the PO; building scenarios for testing Looking forward at releases and what must be in the next release.Sprint •Agile Sprint •Analysis 1 •Scrum 2 •Stories
  22. 22. ANALYSIS HAPPENS – FOCUS ON THE SKILLS I have been a BA (and always will be) You know what I mean! I am now learning to be a ScrumMaster and Agile Coach Its an ongoing process So what have I seen that a Business Analyst can actually do as part of an agile team to ensure the practices of business analysis are not missed out during the development process? Don’t get bogged down in the detail too much. JDI
  23. 23. LET ME TAKE YOU THROUGH A TYPICAL DAY… Take a look at the Burndown first thing Mosey over to the scrum board Have a standup with the team Check in on confidence - just to get a feel of where we are and if were going to make it by the end of the sprint Talk about the blockers Diagnose any problems with the team Go get things moving Groom the Product backlog with the team and the product owner Lets play some poker Run through some demos with our product owner Check things meet our team Definition of Done Prep-just in time for our review Show the business working software
  25. 25. THE GOOD THINGS I SEE… The BA not working in isolation The BA always in constant flux with product owner, testers, developers, architects, Not a lot of artifacts being maintained No business requirements document updates No functional spec changes No change request matrix being updated No time recording overhead … Just enough detail through conversations and clarification and coordination amongst the team
  26. 26. WHAT THE BA’S TOLD ME…“Just doing it is more fun”“I enjoy seeing the users getting a piece offunctionality each sprint”“More enjoyable”“Easier to focus on the current work”“Quicker than waterfall - dont have to wait 6months to see something working”“Clarifying things when we get to them”“Not getting too ahead of ourselves”“Producing working software quickly”“Not working on functionality that wont be used”
  27. 27. WHAT’S CHANGED? Before The BA works with the business on the BR’s and documents the Business Requirements Document The BA also works on getting the BR Doc Signed Off The BA also works on the Functional Specification The BA also works on getting the FS signed off The BA also does a bit of the PM’s work…Sprint •Agile Sprint •Analysis 1 •Scrum 2 •Stories
  28. 28. STORY WRITING WITH PRODUCT OWNER (PO) After The BA works closely with the PO Write clear User Stories that explain WHAT the PO wants The BA uses their skills to elicit the requirements The BA assists with UI and UX criteria with the PO The BA helps document these against stories as Acceptance Criteria and Conditions of Satisfaction As a <user> I want <something> So that <I get to do this>
  29. 29. USER STORIES – THE DETAIL Clarification with the PO on Acceptance Criteria (AC) Contains sufficient detail Allows testers to start thinking of how they are going to test the functionality Allows coders to know more about “What” they are supposed to be building The testers start driving the code with Tests (TDD) Can be at a high level Can be detailed Conversations with the team
  30. 30. THE BA IS NOW FREE… TO USE THEIR SKILLS The BA is in the team Making sure the analysis is done Check-ins with team Works closely with the Tester in a Test Driven Development environment Focus is now on the Analysts skills, not on documents and artifacts they produce Focus is on utilizing the Analysts skills to produce working software – value to the customer
  32. 32. MAINTAINING AND UPDATING THEPRODUCT BACKLOG Stories that do not provide sufficient detail in the AC’s will need to be broken down into smaller stories. Analysis of this detail goes on during a sprint in the background - Grooming Getting ready for the next sprint or two Working closely with the POSprint •Agile Sprint •Analysis Sprint •Backlog 1 •Scrum 2 •Stories 3 •End
  34. 34. STORY PREP FOR GROOMINGThe BA helps ensure only prepped Stories arebrought to the Grooming session.
  35. 35. GROOMING THE PRODUCT BACKLOG- WITH THE TEAM Backlog Item Highest Priority We need these Backlog Item done in 2 weeks! Backlog Item Backlog Item These aren’t critical, but it Backlog Item would be nice. Backlog Item Backlog Item Not having these Stories isn’t Backlog Item Lower hurting anybody. Backlog Item Priority
  37. 37. Scenario – Sprint 19 • We are in to our 4th release of the software • It is day 9 of our 19th Sprint (2 week long sprints) • The team is feeling under pressure as they have only completed 1 of the 7 stories they committed to in sprint planning. • There is no way everything will be done ready for the review, which is tomorrow.What happened?• What could have caused the team to not meet what they committed to?• What have they learnt?• What could they improve on in next sprint?
  38. 38. Retrospective – Sprint 19IMPROVEMENTS:• Clear ACs• Better grooming• PO clear on implications of story, complexity, after some analysis from team• Clear mockups showing what needs to be displayed• PO has a clear understanding of technology involved/complexity story brings to system• The team wanted to Improve the Sprint planningWhat happened?• What did the team learn?• What could they improve?
  39. 39. Sprint 20• 9 out of 10 stories complete.• Sprint 20 improved but most of the work was tidying up the previous sprint. All stories except one completed• BA was working with the PO closely• BA was clear on their role in the team• Grooming was getting better• Focus on most important stories for the upcoming sprint during grooming• Team was able to task out story for upcoming sprint• Team felt confident that stories were well thought out and good amount of detail
  40. 40. Sprint 21 – Continued Success• All stories complete (12/12),• plus a stretch story (bonus) and all had integrated testing.• Grooming was being done well• Had a lot clearer stories (better grooming prep)• Because the team had worked closely with the PO• BA had been on the team for 3 sprints now• PO with BA’s help was bringing clear Stories, AC, and screen mockups to the team sprint planning• Everyone on the team seemed happier• The business was really happy…• Tell the world, and keep working on it.
  41. 41. “I believe the role of analysis is vital, and that a good business analyst is of benefit to any team. However, the temptation for an experienced analyst to slip back into being a buffer between the IT team and the customer, enabling each to become lazy in communicating with the other, is a constant danger” - Dec 8, 2008 4:35 AM by SPIn response to by Shane Haste
  42. 42. THANK YOU So your day as a Business Analyst on an agile project has just got full! Stephen Reed – •Agile Sprint •Analysis Sprint •Backlog 1 •Scrum 2 •Stories 3 •End