Agile frameworks: SCRUM cd, Scrumban, XP Project Management Katarzyna Wasielewska-Michniewska [email protected] User stories

• short, simple descriptions of a feature told from the perspective of the person who desires the new capability; can have different level of detail • More than requirements -> After reading a user story, the team knows why they are building what they're building and what value it creates. • details added as Conditions of Satisfaction (similar to tests) • As a < type of user >, I want < some goal > so that < some reason >. User Stories - Examples

• As an Investor, I need to see a summary of my investment accounts so that I can decide where to focus my attention. • As a Customer, I need to place an order so that I can have food delivered to my house. • As a student, I’d like to be able to search the course offerings, so that I’ll be able to find an offering that most interests me. The attributes of a good user story

• Independent • Negotiable – story is an invitation to conversation • Valuable – story should deliver exact business value • Estimable - story has to be able to be estimated or sized so it can be properly prioritized • Small – for 2 weeks sprint, 3-4 days of work are suggested • Testable – story should include acceptance criteria Product Backlog Iceberg

Source: http://managedagile.com/product-backlog-grooming-iceberg/ SCRUM - Estimations

• In Product Backlog team has to estimate items • Story point = an abstract measure of effort required to implement a user story e.g.: • 1,2,4,8,16 • XS = 1, S = 2, M = 5, L = 13 , XL = 20, XXL = 40 ( known as “T-Shirt Sizing”) • Fibonacci sequence: 1,2,3,5,8,13,20,40,100 • Baseline story – a story that everyone can resonate with (not necessary smallest); sizing of all the user stories should be initiated by comparing them against the baseline • What to consider when sizing? • The amount of work to do • The complexity of the work • Risk or uncertainty in doing the work • Time / Duration Story points vs Task hours • A story point is a high-level estimation of complexity involved in the user stories, usually done before sprint planning, during release. • Story points along with sprint velocity provide a guideline about the stories to be completed in the coming sprints. Source: https://docs.ca.com/en-us/ca-agile- central/saas/sizing-and-estimates-overview • The hour based estimation is a low-level estimation used to represent the actual effort in man hours needed to complete all the tasks involved in a user story. • Hour based estimation should be used when the task estimations in sprint planning. Planning Poker

• A playful approach to estimation, used by many Agile teams. • The team meets in presence of the customer or Product Owner. Each team member holds a set of playing cards, bearing numerical values appropriate for points estimation of a user story. • The Product Owner briefly states the intent and value of a story. Each member of the development team silently picks an estimate and readies the corresponding card, face down. When everyone has taken their pick, the cards are turned face up and the estimates are read aloud. • The two (or more) team members who gave the high and low estimate justify their reasoning. After brief discussion, the team may seek convergence toward a consensus estimate by playing one or more further rounds. Excercise 1. List user stories to be sized 2. Put them in order from smallest to largest • Take the first user story • Then take the second user story • Decide which is bigger and put the bigger one above • Then take the next one and decide where it fits relatively to the other two • Repeat the process until all the stories are now in the list 3. Size the stories • Start from the bottom and give that story a number 2 story points. Giving ‘2’ provides you the room to give a smaller story ‘1’ if discovered at a later stage. • Look at the next story and decide how big is that story as compared to the first one • Continue until you have a size on each story • Use these set of numbers [influenced by Fibonacci] while sizing: 1, 2, 3, 5, 8, 13, 21 Scrumban

SCRUM for development projects SCRUMBAN for maintenance projects

KANBAN for suport projects Scrum

Scrumban

Source: https://www.agilealliance.org/ what-is-scrumban/ Scrumban 1

• gives teams the flexibility to adapt and change to stakeholder and production needs, without feeling overburdened by their project methodology • combines the structure of Scrum with the flow-based methods of Kanban • From SCRUM: • Iteration planning at regular intervals, reviews and retrospectives • Decide how much work they can pull into the sprint • Prioritization on demand -- provides team with the best thing to work on next • Assure necessary level of analysis before starting development (Definition of Ready) • Use “ready” queue (between Backlog and Doing) to organize Scrumban 2

• From KANBAN: • Pull system and continuous workflow: Pull items into Doing as the team has capacity • Work in progress limits • Individual roles not clearly specified • Short lead times - emphasize just-in-time analysis and planning • Use process buffers and flow diagrams to expose process weaknesses and identify opportunities for improvement • Focus more on cycle time than burndown • Use policies to make process step transitions clearer When to consider Scrumban?

• Maintenance projects • Event-driven work • Help desk/support • Hardening/packaging phases • Projects with frequent and unexpected user stories or programming errors • Sprint teams focused on new product development • Work preceding sprint development (backlog, R&D) • Work following sprint development (system testing, packaging, and deployment) • If Scrum is challenged by workflow issues, resources and processes Scrumban board 1

Source: https://www.workfront.com/blog/rolling-out-scrumban-with-andrea-fryrear Scrumban board 2

Source: https://www.agilealliance.org/what-is-scrumban/ Extreme Programming (XP) 1

• a framework which focuses heavily on ensuring the quality of delivered software and which prescribes engineering solutions towards that end • an XP engage in Release Planning and Iteration Planning • work in very short development cycles so that changes requested by the customer can be incorporated frequently • a dozen core practices including Test Driven Development, Customer Testing, Continuous Integration, Small Releases and Pair Programming, XP works towards a continuously improving, high quality product which can respond to changes in customer requirements XP Practices 1 XP Practices 2

1. Coding Standards – keep the code consistent and easy 2. Collective Ownership – everyone contributes new ideas to all segments of the project 3. Continuous Integration 4. On-Site Customer 5. Pair Programming 6. Planning Game 7. Refactoring 8. Short Releases 9. Simple Design 10.Sustainable Pace (40 Hour Week) 11.System Metaphor 12.Test-Driven Development Extreme Programming (XP) 2

Source: https://blogs.msdn.microsoft.com/jmeier/2014/06/06/extreme-programming-xp-at-a-glance-visual/ Values of XP

• Simplicity - teams accomplish what has been asked for and nothing more • Streamlined communication – teams work together on any part of the project; any concerns or problems are addressed immediately • Consistent, constructive feedback - teams adapt their process to the project and customer needs • Respect - each person on the team, regardless of hierarchy, is respected for their contributions; team respects the opinions of the customers and vice versa • Courage - team members adapt to changes as they arise and take responsibility for their work Rules of XP Scrum vs XP

• In Scrum, teams and meetings are fairly fixed whereas the question of how work actually gets done is left to the teams to decide. XP comes with a set of core practices that could seem overwhelming to the Agile beginner. • Scrum is a methodology, which is more concerned with productivity while XP is more concerned with engineering. • XP teams work on items in a strict priority order whereas a Scrum team might not necessarily tackle each item in priority order once in sprint. • XP teams can bring new items of work into an iteration and switch out items of equivalent size (as long as they haven’t been started) if the customer decides on a new priority.