Agile Training – Agile Overview

About Me Michael S. Rosenberg Certifications: Certified Scrum Professional Certified Scrum Product Owner Certified Scrum Master Publications: Creating High-Functioning Development Teams Tending to the needs of individual members on an Agile team http://bit.ly/1P0lndz If you have questions, email me at msr@thriveinagile.com Trained full Scrum teams and Product Owners in: United States | China | Poland | India | Spain

Why Are We Introducing Agile When we were small, everyone was able to work together very quickly. We could make changes or do new development on a whim Now that we have grown in size, there are a lot of moving parts. We need to introduce an organizational process that allows us to remain nimble, fast paced and innovative and work with precision

Agile Umbrella Less Process, More Adaptive Development Teams Quick turnaround Teams

Agile Overview Iterative development Iterative development is a way of breaking down the software development into smaller chunks. In iterative development, feature code is designed, developed and tested in repeated cycles. Inspect and adapt product and process during development Quicker time to market Agile development allows for changes at times during the process because is it more nimble

What Agile Looks Like 24 Hours 2 – 4 Weeks

What are the Focuses in Agile? Does not mean No Documentation

Agile Manifesto Highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage Working software is the primary measure of progress Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale Business people and developers must work together daily throughout the project Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done http://agilemanifesto.org/principles.html

Core Agile Principles Eliminate Waste Characteristic Dimension Eliminate Waste Spend time only on what adds real customer value Amplified Learning When you have tough problems, increase feedback and collaboration Leave Options Open as Long as Possible Maintain multiple options and decide on options as late as practical, but no later Deliver as Fast as Possible Deliver value to customers as soon as they ask for it Empower the Team Let the people who add value use their full potential

Benefits for Business Quicker ROI Lower Costs Faster Time to Market Deeper relationships with Stakeholders and Clients Quicker Response to Change Less Risk

Agile Team / BA

Development Team Responsible for building the product with high quality. Cross-functional, with seven (plus/minus two) members Selects the Sprint goal in collaboration with the Product Owner Is empowered to make decisions on how work is done, who does it and how the process will evolve Organizes itself and its work Demonstrates work results to the Product Owner and Stakeholders

Product Owner Role Sets product vision Manages Product Backlog Decides Release Dates Reviews work (approves in UAT) Maximizes the value of the work done Improves Team ROI Encourages development team to grow

BA Role Plan work for the product’s current sprint Work with business stakeholders to define features, functionality and user stories The middleman between business and development Create acceptance criteria

User Stories Simple descriptions of desired functionality Contains all the information needed for developers and QA to meet acceptance criteria Written as a story from the perspective of the product user Explains what the user wants Explains why they want it The size of a user story is expresse d in terms of “Story Points” 1,2,3,5,8,13 As a <user role> I can <do something> so that <I get some value>

User Story Example As a fund administrator I want the capability to quickly generate a closed period investor transaction report for all the funds I manage so that I can verify investor balances

User Stories – Problem Solvers Software requirements are a common communication problem. Requirements are often not thought of until development has started A lot of information is missing in the original request User Stories give all requirements upfront before development. The stories the team picks up for a sprint is what they agree to develop. Changes may be accepted unless they change the dramatically change the time estimate.

Epics What is an Epic Epics are simply larger user stories They have not yet been broken down to appropriate size There is little to no detail, few requirements or acceptance criteria Epics are the basis for what will be developed in the future Stakeholders should always be thinking towards the future by planning Epics As you get closer to development on these stories Details get more and more clear The story divides into multiple, smaller stories that can be worked on over a few sprints Acceptance criteria is developed By the time it gets into the hands of developers ALL THE REQUIRMENTS HAVE BEEN FLUSHED OUT

Product Backlog Living Document – Always growing as new stories get added Groomed Stories All requirements gathered Fully broken down Fully estimated Prioritized Ready for development Ungroomed Stories Some requirements met More broken down Not estimated Not ready for development Need More Information Epics Not all requirements received Less broken down To large to develop in one sprint Not estimated Not ready for development

Backlog Hierarchy Business Goals Planning Implementation Epic User Story Tasks Tasks Tasks User Story Tasks Tasks Tasks Tasks Tasks Tasks User Story Tasks Tasks Tasks User Story Product Backlog Sprint Backlog

Team Sprint Capacity How do we know how much work a team can handle? At the beginning of each Sprint Cycle we figure out the teams available capacity in terms of working hours during sprint. this shows us what a teams capacity is in terms of working hours. We also estimate the size of the tickets (stories) in terms of effort – because we realize that not all developers work at the same speed (Story Points) This gives us a running team velocity, or how many tickets the team can handle on average

When We Know the Capacity Once we have velocity we know how much a team is physically able to do. We plan work based on: Historically how much they can complete + work availability This means developers always have a maximum amount of work to complete If the team is has a capacity of 35 points and are working on 7 stories totally 35 points, if someone asks to bring in another story equaling 5 points, one of the current stories in the sprint needs to be dropped to fit it in

(In Scrum) Sprint Planning Sprint Backlog User Story Tasks Product Backlog (Committed Product Backlog Items) Stories are reprioritized before finally going into the sprint

(In Scrum) Sprint Sprint Backlog User Story Tasks (Committed Product Backlog Items) Sprints are time boxed development periods that usually run between 2 – 4 weeks Each sprint developers work off of a “Sprint Backlog” which contains the stories they agreed to work on before the sprint started.

All Scrum Events Sprint: Time boxed Development Cycle 2 - 4 weeks Daily Standup: For development team 15 min max Sprint Grooming: Team reviews and estimates new stories 1- 2 hours per week Sprint Planning: Review stories with team 1 – 2 hours per week Sprint Review: Held at the end of the sprint to inspect the increment Sprint Retrospective: Team meets for 1 - 2 hours at the end of each sprint to inspect and adapt the process

Putting the Planning Together Product Vision Roadmap Product Backlog Sprints Sprint Backlog Tasks for development Sprint 1 Sprint 2 Sprint 3 Sprint 4 Release Release Release

Putting it all together….

Agile Training – Agile Overview