OIT uses Scrum, an Agile framework for completing complex projects. The purpose of this page is to provide helpful information and resources to learn more about Scrum. It is not intended to be an exhaustive resource, and it is not intended to be prescriptive: scrum is a toolkit for finding the process that works for you in your situation, and your needs are more important than staying true to the ideology.

Before you begin: talk to a Scrum Master

If you're interested in trying Scrum, consider contacting a practicing OIT Scrum Master. They are happy to walk you through the roles, events, artifacts, and rules of Scrum. Ask to attend a few of their sprint meetings! Seeing Scrum in action is one of the best ways to learn.

Practicing OIT Scrum Masters:

Brian Lance blance@uci.edu, DUE Data & Development
Mel Layos mlayos@uci.edu, UC Recruit Application Support
Erik Kelly erkelly@uci.edu, Academic Web Technologies
Victor Pham phamvd@uci.edu, Chancellor & Provost IT

There is a standing Scrum Master's Forum every Monday at 2pm in OIT ConfRoom MSTB 232. If you are interested in starting a new Scrum team you are more than welcome to join in.

What is Scrum?

Scrum is an agile way to manage a project. Instead of planning everything up front, Scrum teams plan and deliver a product iteratively, aiming to avoid rework and focus more effort on what the stakeholders find useful. Scrum iterations are called "sprints" and typically last 2 weeks (some teams standardize on 3 or 4 weeks, and some go for 1-week sprints).

Compared to traditional project management or waterfall, Scrum typically has less documentation, more customer and team collaboration, more frequent releases, and regular events to facilitate team process improvements.

Scrum is not a silver bullet, and you will still have to make hard choices about value, priority, and risk. But unlike waterfall, making those choices at the right time and with the right people is central to the scrum ethos, and are a part of the process.

Scrum Roles

Scrum defines a few roles that allow us to know who's doing what:

Product Owner: responsible for determining (adjusting) product backlog priorities and defining the user stories (requirements). Ideally, it is the functional stakeholder, but others can serve as a stand-in for the stakeholders and users.
The Team: do the work of delivering a potentially releasable product increment. The team has their bacon on the line.
Scrum Master: responsible for ensuring Scrum is understood and enacted. They are the servant-leader and facilitator for the Team.

Please see the Scrum Alliance Scrum Guide for more complete information on Scrum and the roles involved.

Sprint Planning

Before the sprint, the team works with a Product Owner to develop the product/project vision statement and begin gathering high-level needs and documenting requirements using cards. Requirements can take form in physical or virtual cards containing some or all of the following information:

User story or job story
Acceptance criteria. This defines what must be true in order for the card to be considered "done". See the related Definition of Done.
A task list that comprises all the individual things that the team must accomplish before the story is complete. These tasks can be part of the Definition of Done (e.g. quality assurance), or unique to a given story (e.g. reach out to the stakeholders and get instructional text).
Mockups, screenshots, original support request, etc. Any other assets that are helpful in the development lifecycle.
Comments & implementation notes. Using virtual cards allows for longer-form conversations, which are helpful in exchanging information outside of the standup if folks aren't co-located
Test cases and bug notes. List of defects, steps to reproduce, and notifications of when bugs are fixed
Links to other artifacts. GitHub issues, pull requests, external data sources, etc.

Typically the Product Owner will be most involved with the user/job story and acceptance criteria definition.

The team then holds a sprint planning meeting, where the team commits to delivering a set of cards within the sprint period. The team takes this commitment very seriously, and as result, much of the sprint planning meeting is dedicated to figuring out what deliverables are achievable within this short window of time. Before the team can commit to delivering a card, they must fully understand the requirements and estimate the size and complexity. After a few sprints the team's average velocity will emerge and the team will become more reliable at meeting commitments.

It is important to note that team consistency greatly contributes to establishing a predictable velocity. When a new scrum team is formed, initial sprints will typically result in lower velocity than is the full potential for the team. As more sprints are completed with the same team, sprint team's dynamics, strengths, and weakness become more evident resulting in story assignments that are better suited for specific team members. When a team makeup changes across sprints, the new team member(s) introduces an "unknown" factor that will require few sprints for the team predictability to stabilize. Therefore, it is strongly recommended to maintain team consistency as much as possible to get the best results.

Committing to deliver a set of cards within a sprint is a team decision: the Product Owner and other non-team members assist by providing information and clarification only. As such, the team collaboratively estimates each card and jointly decides whether it will "fit" within the sprint. Many teams use an agile consensus-based estimation technique called Planning Poker to make these decisions, which facilitates discussion and encourages all voices to be heard.

Daily Standups and the Sprint

Every day the team comes together for a 5-15 minute daily standup. At this meeting the team talks about what they're doing. Classic scrum has each team member note what they did yesterday, what they plan on doing today, and identify any impediments that they're facing. At OIT, all our teams have moved to using the "run the board" process, where the whole team talks about each card in the current sprint, letting each member speak up as necessary. Team members volunteer their assistance in an effort to quickly remove impediments. With only a few weeks to deliver from design to testing, an unresolved impediment can very quickly lead to a missed sprint commitment.

Some sprints resemble a mini waterfall process where design, implementation, review, testing, documenting and deployment to demo server happens all within 2 weeks. But due to the fast-paced, collaborative process, you typically see the lines between phases are more blurry than in waterfall, with team members working together to find the best solution.

The team's shared responsibility for delivering means that everyone helps to make the process better. Automated tools for testing and deployment are often brought in to support frequent releases, both to testing environments and to production.

End of Sprint

At the end of the sprint the team Demos their potentially shippable release. The Product Owner provides suggestions for incorporation into future sprints. Ultimately the Product Owner will accept or reject the release. If accepted, the release is deployed. Early in the project this may mean deploying to a pre-production or test server, but the important part is that it is released. A release demonstrates that there are no loose ends or subsequent tasks needed before the release is usable by users. If the release is rejected by the Product Owner, then the group discusses what changes are necessary in order to launch.

Following the demo is the Sprint Retrospective. The goal of this meeting is to continually improve the team's process by discussing what's working well, what isn't, and to identify changes they'd like to make. Retrospectives are team-building experiences that are meant to be productive, fun, and sometimes uncomfortable as the team works through issues. Consider keeping retrospectives fresh and interesting by trying out new activity ideas from tastycupcakes.org and funretrospectives.com.

The team and the Product Owner then begin again, starting a new sprint by planning what's most important to get done next.

Scrum Artifacts

Product Backlog: prioritized list of everything that might be needed in the product
Sprint Backlog: the set of the Product Backlog items selected for a Sprint. Teams use index cards, Trello, or other tools to track progress
Burn-downs, burn-ups, or cumulative flows: used by some teams to track progress towards the goal

Benefits of Scrum

Each stakeholder often sees a different reason to use Scrum. The following are benefits OIT Scrum teams have observed from using Scrum:

Customers get:
- Transparency & trust: regularly see evidence of project progress at demos, standups, etc...
- Effectiveness: team focuses on delivering the highest value functionality first
The Team gets:
- Empowerment: teams decide how to deliver potentially shippable increments, increasing ownership
- Efficiency: teams organize and manage their own work, leading to improvements in efficiency and effectiveness
- Less risk: the riskier stories are prioritized and tackled first, leaving less risk for the later, harder parts of the project
Operations gets:
- Collaboration: developers and operations partner to improve reliability, security, and speed
- Speed: Releasing every two weeks (or more frequently) encourages automation, version control, and configuration management
Leadership gets:
- Customer-focus: teams collaborate with customers and routinely ask for their feedback, leading to improved results
- Innovative: self-organization can promote a more innovative and creative environment
- Staff engagement: team buy-in and shared ownership are essential to employee satisfaction and engagement
- Cross-training: peer reviews, collaborative planning, pairing, etc... spreads knowledge throughout the team, reducing the bus factor

Scrum Resources

Please consider adding resources that have been useful to you in adopting Scrum.

Reading:

Web: Scrum Alliance Scrum Guide: does a much more thorough job at explaining Scrum than this guide
Book: Agile and Iterative Development - A Manager's Guide: research and case studies for folks considering Scrum or other Agile methodology

Training:

Scrum Master training: CollabNet and Mountain Goat Software offer useful training for anyone, not just for Scrum Masters