SCRUM basics Julie Rudder & Claire Stewart

What is scrum (Claire) Scrum roles (Claire) Scrum rhythms and processes (Claire) How to write stories (Julie) How to decompose to tasks (Julie) Rules! team pulls work, etc. (Julie) Outline

What is Scrum? Agile project management methodology Agile Focus on reducing complexity by breaking down work Short work cycles with frequent deliverables, iteration Emphasis on making work visible

Scrum roles Product Owner Scrum Master Team Stakeholders The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders. Drives work by writing stories, and decides when they are done. Available to the team. The person responsible for ensuring the Scrum process is used properly and facilitating resolution of issues raised by the Scrum Team. Does not direct the Team, but facilitates their work. A cross-functional group of people responsible for managing itself to develop the product. Breaks down Stories into Tasks & executes them. The people for whom projects are completed. They are directly involved only during sprint reviews.

Source:

Traditional components of Scrum ComponentDescription SprintTime-boxed work period to complete planned stories (2 weeks for us) StoriesProjects that result in a discrete deliverable and can be completed within a short time, hours or days TasksSmaller increments of work; every story is broken down into tasks EpicsLarge initiatives that have multiple stories Product BacklogList of prioritized stories that have not been started Sprint BacklogDetailed list of stories for the current sprint Sprint PlanningFull-team session to create tasks and effort for stories on the sprint backlog and volunteer task ownership Daily ScrumsFull-team updates on project progress Sprint RetrospectiveFull-team session to evaluate previous sprint’s success, both in deliverables and in process. DeliverablesDiscrete work outputs – may be milestone or epic completion

The Board

Story Format As a: I want to: So that: Done looks like:

Story Format As a: I want to: So that: Done looks like:

Story Format As a: I want to: So that: Done looks like:

Story Format As a: I want to: So that: Done looks like:

Story Format As a: I want to: So that: Done looks like:

How to write stories: Good stories Stories are told from the perspective of the user. Stories are understood by the team and can be broken into discrete tasks. Stories contain work that are to be done by the team. Stories are ready to be started. Stories have acceptance/done criteria.

Bad story - too big

Bad example - too big

Better story As a: System Administrator I want to: easily integrate my campus authentication system with Curate. So that: users at my institution can log in with their campus credentials. Done looks like: Curate has a flexible authentication system that allows new institutions to configure their campus preferred authentication system without writing new code. Common systems are CAS, LDAP, SHIBBOLETH, and more.

Sizing Stories Assign a value to each story to measure COMPLEXITY and SIZE of the story relative to you team. Sizing helps us: ●locate unknowns in the work and add needed information ●build team consensus of the work to be done

How to size 2 = very fast and easy to do in small amount of time and effort = too big, too unknown - needs to be broken down into smaller stories

Most stories should be around 2 = very fast and easy to do in small amount of time and effort = Too big, too unknown - needs to be broken down into smaller stories

If sizing is all over the place

Team members explain why they assigned certain numbers.

If sizing is all over the place Team members explain why they assigned certain numbers. Team comes to consensus about the size.

Decompose stories to tasks Tasking is not a way of accounting for time spent but a way to keep atomic chunks of work in front of people's eyes, so that the team can see at a glance what is available to do and what may be blocked.

Rules! Team driven work Pull your own work (tasks) Standups exist for the team - team members should address the team without worry of being too technical, it’s not a report to POs All team members required to attend stand up (of course you will be out sometimes) Show up on time, end on time Make your work visible

Discussion, questions It can take a little while to get used to Scrum! What questions do you have?