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.
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:
Scrum is an agile way to manage a project. Instead of planning everything up front, Scrum teams plan and deliver a product iteratively. 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.
Before the sprint, the Product Owner, team, and potentially others develop the product/project vision statement and begin documenting high-level needs/requirements using cards. Requirements take form in physical or virtual cards containing the following information:
Typically the Product Owner will be most involved with the user/job story and acceptance criteria definition.
The goal of the sprint planning meeting is for the team to commit 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/complexity. After a few sprints the team's average velocity will emerge and the team will become more reliable at meeting commitments.
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.
Every day the team comes together for a 5-15 minute "daily standup". At this meeting each team member addresses what they did yesterday, what they plan on doing today, and identify any impediments that they're facing. Team members volunteer their assistance in an effort to quickly remove impediments. With only 2 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. Typically the lines between phases are more blurry than in waterfall given the fast-paced, collaborative process. Automated tools for testing and deployment are critical to support frequent releases.
At the end of the sprint the team demo's 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. This 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.
Please see the Scrum Alliance Scrum Guide for more complete information on Scrum and roles involved.
Each stakeholder often sees a different reason to use Scrum. The following are benefits OIT Scrum teams have observed from using Scrum:
Please consider adding resources that have been useful to you in adopting Scrum.
Reading:
Training: