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
...
- 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:
...
- 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. This might take the form of a checklist for one team member to accomplish, or a group of individual tasks that can each be done independently
- 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. Virtual Using virtual cards allow 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.
...
Every day the team comes together for a 5-15 minute daily standup. At this meeting the team talks about what they're doing. For small teams, Classic scrum has each team member can address note what they did yesterday, what they plan on doing today, and identify any impediments that they're facing. Larger teams often find it more helpful to At OIT, all our teams have moved to using the "run the board" and talk 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.
...
- 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
...
- 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
...