1. Agile Training – Agile Overview

2. 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
If you have questions, me at
Trained full Scrum teams and Product Owners in:
United States | China | Poland | India | Spain

3. 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

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

5. 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

6. What Agile Looks Like
24 Hours
2 – 4 Weeks

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

8. 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

9. 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

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

11. Agile Team
/ BA

12. 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

13. 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

14. 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

15. 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>

16. 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

17. 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.

18. 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

19. 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

20. 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

21. 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

22. 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

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

24. (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.

25. 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 hours at the end of each sprint to inspect and adapt the process

26. 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

27. Putting it all together….

28. Agile Training – Agile Overview