The Business Analyst Role in Agile Projects

1. The Business Analyst Role in Agile Projects Dananthi Arnott, Agile Coach and Trainer LinkedIn

2. What are your choices? • Path One : Transition to a “Product Owner” role and help drive the project and manage the Product Backlog • Path Two: Assist the Product Owner as the “Technical Product Owner” – Write User Stories (Requirements) and Acceptance Criteria; Manage the Product Backlog; provide feedback; respond to change; collaborate with team; manage Stakeholder expectations

3. Product Owner Role Iterative and Incremental Development Project time line Refer to Slide note : Agile Project Life Cycle

4. Note on how to create the Initial Release Plan and/or Create the Project Charter: Establish the high level scope and schedule for the project to obtain project funding and for managing stakeholder expectations. Who takes part in this? May be a subset of the team or perhaps you can get this information from your stakeholders as well. Don’t forget to capture constraints, assumptions and risks. The initial release plan is at a high level, rough and only detailed enough to get the project started. It will evolve as more information is known about the product, development environment and the team velocity. The goal is to establish an overall release schedule that presents the timeline in Iterations and defines the preliminary scope that will be delivered at the end of each Iteration. Release planning can be driven by either the project scope or the project schedule. • If scope drives the project, the goal of the Initial Release Plan is to define a preliminary schedule of work items planned for each Iteration and provide an estimate of the number of Iterations required to deliver the project scope. This is based on the team velocity. • If schedule drives the project, the goal of the Initial Release Plan is to define the scope that can be delivered at the end of each Iteration, based on the team velocity. This provides an estimate of the number of features that can be delivered for the Project. Suppose it does not go as planned, and you have to stop the project due to any one of these reasons: • Budget has been depleted or • All features in the PBL is ready to be deployed (scope is met) or • Run out of time…scheduled date for delivery has approached. Your Key to success: Highest priority items in the PBL has been worked on and is ready for delivery.

5. Iterative and Incremental Development Backlog                         Project time line          Refer to Slide Notes:

6. Success Criteria for Managing the PBL Backlog A well-groomed and managed Product Backlog is a prerequisite for creating a successful product. How? • Stories must be well written : • How many stories? • how much detail ? • when should they be done? • Stories must be prioritized (Business Value, Risk, complexity…) Key Responsibility: define requirements in smaller increments, prioritize and work more collaboratively with the team to build product iteratively and incrementally Refer to Slide Notes:

7. FAQ: How do you address the architecture decisions that you need to make at the beginning of a project? The teams incorporate software architecture in to the agile framework, delivering iteratively and incrementally. It is especially critical to make sure these iterations have definite goals and some of these tasks are time boxed. One common approach is called Sashimi. Couple of great articles providing in depth discussion on the topic. http://www.executivebrief.com/blogs/software-architecture-agile-environment-sashimi-approach/ http://msdn.microsoft.com/en-us/architecture/ff476940.aspx

8. Project Kickoff Meeting [= Sprint 0 = Iteration 0] • Inputs: Project Charter; Historical Data; Background Information; High level Scope (requirements) should be prioritized in relation to Business value ; Time Lines … • During Iteration zero, the highest priority requirements are further refined and detailed. This is done in collaboration with the team. • The meeting takes place beforeany development begins and should be time boxed. (recommendation: 1 week) • Output: • Create an Initial Release Plan with the team (why?) • Initial Estimate in Story Points • Risks • Constraints • Make sure the stories in the Product Backlog is detailed enough in readiness for the first two iterations.

9. More on the … Project Kickoff Meeting [= Sprint 0 = Iteration 0] • Activities during this Iteration: • Introduction of the team (core and external team members) • review the Project Charter (Project Risks, Constraints and Assumptions) • Sharerelevant background information and/or historical documentation • Discuss the initial Release Plan (Road Map; Vision …) • Discuss functional and non-functional requirements • Discuss supported platforms, installations, architecture, security, build frequency and product shipment format • Setup necessary project infrastructure (Team) and include tasks to the PBL if needed • Discuss Beta Releases and the scheduling of Landmark Demos (for major milestones) • Review applicable procedures, discuss testing requirements and escalation process

10. More on the Project Kickoff Meeting (Contd.) • Activities during this Iteration (contd.): • Review the team Definition of Done and agree on the Project Definition of Done. LinkHowTo • Decide the Iteration Length and start dates, venue and times for Daily Stand-Up, Planning meeting, Demo/Review, Retrospective etc. • Evaluate the skill set of the cross functional team members and training requirements • Review lessons learned and/or improvement action items from previous Project Retrospectives • ============== • Populate and refine the product backlog with enough stories for the first two Iterations of the project… more detail (why?) • Provide relative estimates for stories in the PBL in Story Points (How? and why?) LinktoStoryPointEstimation • QUALITY – Provide answers to the team on learning WHY? and WHAT? Put it into context.

11. What happens during the Iterationand how do you prepare for the meeting? • Input: • Prioritized Product Backlog • Stories written with just enough detail (follow the 3 Cs. Card/Collaboration/Confirmation) • Make sure you have acceptance criteria defined for each story

12. Are you ready for Iteration Planning? • Input: • Prioritized Product Backlog • Stories written with just enough detail (follow the 3 Cs. -Card/Collaboration/Confirmation) • QUALITY - Make sure you have acceptance criteria defined for each story (Provide context for the story scenario) • At the Iteration Planning meeting: • Explain the highest priority stories to the team at the Planning meeting • Get estimates at the Planning meeting in Ideal hours • If the stories are too big, break them down in to smaller stories or tasks • Review Acceptance Criteria • Review the Definition of Done for the Iteration • As a team, decide on an Iteration Goal that describes the Product increment that will be delivered in the Iteration • Risk discussion (Schedule, meeting the Iteration Goal, team capacity) • Output: a committed list of work items for the Iteration (Iteration Backlog)

13. During Iterations • QUALITY – “Power of 3” – Include all team members (Product Owner, QA, Developer) in discussions and meeting decisions • Ensure the team is meeting the Definition of Done for completed stories and tasks Iteration Demo/Review • Review what was accomplished and what was not completed • Accept or Reject work; provide feedback • Get feedback from Stakeholders: • How useful is the product? • Does it serve the intended purpose? QUALITY – Provide honest and timely feedback on completed stories. Include key Stakeholders to the Demo/Review Landmark Demo: Can be used for reviewing related functionality with project sponsors and stakeholders. This is a special demo that is open to a larger audience. Similar to a milestone review, in this case you are demonstrating potentially shippable software or a beta release.

14. Managing and controlling new Information and changes to the Product Backlog • Estimate new work items in Story Points • Reprioritize Product Backlog • Revise Scope/Schedule • Update the Release Plan • Communicate the changes to all stakeholders Key: maximize business value and customer satisfaction; minimize risk

15. What else? • Continuous Release Planning Scope Cost Quality • Some factors that can have an impact on the Baseline Release Plan are: • New and emergent technology • Architecture Design • Domain Knowledge • System design • New information based on spikes related to research, proof of concepts • Team changes • Team expertise • Training • If these factors cause the Release Plan to be revised, the impacts must be communicated. Risk Time Project time line

16. What else? Cost Scope • Continuous Release Planning Quality • Continuous release planning is important (why?) : • Review Release Plan; Inspect and Adapt • Address Quality Issues • Risk impact analysis and risk mitigation • Manage Stakeholder expectations • Manage and control project scope • Manage the project schedule Risk Time Project time line

17. Iteration /Project Retrospective FEEDBACK TRUST • Participate in the Iteration and Project Retrospectives • Provide honest feedback • Be open to receiving feedback from the team and encourage them to provide you the feedback QUALITY – Identify process and product quality issues. What works? What can we improve? RESPECT COURAGE Communication

18. Related Topics • Release Planning on agile projects (Story Point estimations, Epics, Themes, User Stories, Prioritization based on Business Value, ROI, Risk, Dependencies etc. Creating a Release Burndown Chart) • How do you write good stories for agile projects? (Understand Use cases, write business scenarios, write Acceptance Criteria. What does just-in-time mean? Breaking down user stories. How do you apply lean software engineering principles? INVEST model – DEEP?) • How is Quality Assurance done on Agile Projects? What is the Definition of Done and how important is it? How do you stabilize the system being built when you are incrementally creating potentially shippable products? Explore the concept of a Special Iteration? • How do you apply the agile framework to a maintenance project? Explore Kanban? • What is an Ideal hour? What are Iteration Burn down charts? • What is Team Velocity? • Are there metrics on agile project? Can you measure team productivity? Can you compare teams? How do metrics affect team performance?

19. Thank you