Overview
The Agile/Scrum development methodology is not used for every project at Stanford, or even the majority of projects (yet); however, it is increasingly taking the place of the traditional "waterfall" methodology, especially for projects where user requirements are more difficult to nail down with confidence at the start of the project, or for SaaS projects where the vendors' implementations are predominantly Agile (of some sort). From a Project Management Life Cycle point of view, Scrum largely takes the place of the Project Execution/Implementation phase, beginning with user stories that can, but do not necessarily, replace a formal Business Requirements Document (BRD). Often, both are used, with the BRD serving as the high-level document and the user stories as the more user-centric, detailed requirements. All other phases of the Project Management Life Cycle should be followed when using Agile/Scrum, including Initiation, Definition and Planning, Monitoring and Controlling, and Closeout.
Agile came about as a "solution" to the disadvantages of the waterfall methodology. Instead of a sequential design process, the Agile methodology follows an incremental approach.
Developers start off with a simplistic project design, and then begin to work on small modules. The work on these modules is done in weekly or monthly sprints, and at the end of each sprint, project priorities are evaluated and tests are run. These sprints allow for bugs to be discovered, and customer feedback to be incorporated into the design before the next sprint is run.
The process, with its lack of initial design and steps, is often criticized for its collaborative nature that focuses on principles rather than process.
Advantages of the Agile Methodology
- The Agile methodology allows for changes to be made after the initial planning. Re-writes to the program, as the client decides to make changes, are expected.
- Because the Agile methodology allows you to make changes, it's easier to add features that will keep you up to date with the latest developments in your industry.
- At the end of each sprint, project priorities are evaluated. This allows clients to add their feedback so that they ultimately get the product they desire.
- The testing at the end of each sprint ensures that the bugs are caught and taken care of in the development cycle. They won't be found at the end.
- Because the products are tested so thoroughly with Agile, the product could be launched at the end of any cycle. As a result, it's more likely to reach its launch date.
Source: http://www.base36.com/2012/12/agile-waterfall-methodologies-a-side-by-side-comparison/ (external link)
Details
Available Tools
- JIRA, for planning boards, burn down charts, etc.
- FishEye, for read-only view into code repository
Consistent Across Most UIT Agile Projects
| Item | Description |
|---|---|
| Roles and Responsibilities | |
| Scrum Master | Individual held accountable for removing impediments to the ability of the team to deliver the product goals and deliverables; acts as a buffer between the team and any distracting influences. (aka Project Manager) |
| Product Owner | Individual who represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. The Product Owner writes (or has the team write) customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog. (aka Business Analyst) |
| Development Team | Individuals responsible for implementing the user stories/requirements. The Development Team consists of professionals who do the work of delivering a potentially releasable increment of "Done" product at the end of each Sprint. Only members of the Development Team increase the increment. |
| QA | Individual responsible for testing and validating the implementation of the user stories/requirements. |
| Business Owner | Individual responsible for eliciting the requirements and later validating the implementation of the user stories/requirements. |
| Meetings (guidelines for best practice) | |
| Sprint Planning |
The work to be performed in the Sprint is planned at the Sprint Planning Meeting. The plan is created by the collaborative work of the entire Scrum Team. The Sprint Planning Meeting is time-boxed. For example, two-week Sprints have four-hour Sprint Planning Meetings. The two parts of the Sprint Planning Meeting answer the following questions, respectively:
|
| Daily Scrum (Standup) |
The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done for the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, each Development Team member explains:
|
| Sprint Review (Demo) | A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. This is an informal meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. Typically, for 2 week Sprints, this can be a 2 hour meeting. The Product Owner identifies what has been "Done" and what has not; the Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved; the Product Owner discusses the Product Backlog as it stands, and he or she projects likely completion dates based on progress to date; and the entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings. Feedback/issues can become new stories. |
| Sprint Retrospective |
The Sprint Retrospective is an opportunity for the Scrum Team only to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning Meeting. The purpose of the Sprint Retrospective is to:
|
| Artifacts | |
| Product Backlog — required |
The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. The Product Backlog is:
Think of it as a wish list of the things that would make the product "great." |
| Sprint Backlog — required | The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality. It defines the work the Development Team will perform to turn Product Backlog items into a "Done" Increment. It makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal. |
| Increment (Burn down Chart) — required | The Increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new Increment must be "Done," which means it must be in a useable condition and meet the Scrum Team's definition of "Done." It must be in useable condition regardless of whether or not the Product Owner decides to actually release it. |
| User Stories — required |
User Stories are one of the primary development artifacts for Scrum project teams. A User Story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. Stakeholders write user stories, not the developers. User Stories are simple enough that people can learn to write them in a few minutes, so it makes sense that the domain experts (the stakeholders) write them. User stories include the following:
|
| Definition of Done — good practice |
When the Product Backlog item or an Increment is described as "Done," everyone must understand what that means. Although this varies significantly by Scrum Team, members must have a shared understanding of what it means for work to be complete to ensure transparency. This is the "Definition of Done" for the Scrum Team and is used to assess when work is complete on the product Increment. Example definitions:
|
| Vision — good practice | The product vision paints a picture of the future that draws people in. It describes who the customers are, what the customers need, and how these needs will be met. It captures the essence of the product— the critical information we must know to develop and launch a winning product ... since the Product Owner is responsible for the success of the product and its return on investment (ROI), he or she should lead the vision-creation activities through close collaboration with the team.
Source: The Product Vision by Roman Pichler |
| Work Agreement — good practice | Work agreements are the set of rules/disciplines/processes the team agrees to follow without fail to make themselves more efficient and successful ... Team members themselves set these. The ScrumMaster may have to play the role of facilitating the meeting that's held to come up with work agreements, but it is the team that decides on the agreements themselves. The team also reviews them periodically during retrospective meetings.
Source: "Work Agreements for a Scrum Team" (external link) by Vignesh Murthy |
Approaches Used in Actual Stanford Projects
| Topics | AXESS Project (new custom code) | DUO Project (new custom code + 3rd party tool) | SeRA Project (enhancement cycles of custom code to existing base) |
|---|---|---|---|
| Backlog Grooming | Yes | Yes (aka Story Time) | Yes |
| Bug Reports | No, logged as a new story | Yes, linked to story | Yes, logged and linked to the story. Bugs must be fixed before pushing story to the next step in the workflow. |
| Bug Report Priority Used | Not Applicable | Challenges | Yes |
| Business Requirements Document (BRD) | Completed outside of sprints | Completed outside of sprints | Completed outside of sprints |
| Hardening | Not Applicable | Consists of end-to-end regression, run through existing test cases. | Consists of one sprint focused on regression testing and catch-up from prior sprint. At the end of the hardening sprint, exit criteria are reviewed and release is approved by both AS and business. |
| JIRA Input Form | JIRA default form | JIRA AS form | JIRA AS form |
| Management Visibility | Not Applicable | Burn down charts | Planning/work board progress, 2D JIRA gadgets |
| Release Artifacts | Not Applicable | Deployment document (cutover plan), release notes from DDD team, and approvals at sprint level | Release notes, release go-live checklist which includes exit criteria, approval email, and release stories list |
| Sprint Duration | 2 weeks | 2 weeks | Varies based on University calendar (commencement and year-end freeze), pace of the team, etc. |
| Sprint Management (aka Scope Management) | Extend time frame, delivery time changes | Move stories out of sprint (i.e., reduce scope to meet deadlines) and/or extend timeline | Move stories out based on stakeholder priorities; delivery time does not change |
| Sprint Planning Occurrence | At beginning of sprint | At beginning of sprint | At beginning of sprint |
| Sprint Planning Content | Not Applicable | Not Applicable | Development confirmation of scope, final prioritization for release, analysis of top priorities, and estimates |
| Sprint Phasing of Work | Not Applicable | Logical Grouping of Stories | Planner to front-load big or difficult changes |
| Sprint Scope | Dev/QA | Dev/QA/demo/UAT/retrospective.
Note: UAT is reviewed with business lead; no hands-on. |
Dev/QA/demo/UAT.
Note: UAT is hands-on with core business partners. |
| Stand-up Frequencies | Daily | Daily | 2 - 3 times a week |
| Story Content | Not Applicable | Definition of done and acceptance criteria | Summary statement, story details, and acceptance criteria |
| Story Inter-dependencies | Not Applicable | Managed through linked stories or tasks or through the use of sub-tasks | Not Applicable |
| Story Management | Epics/stories |
|
Epics/stories/linked bugs |
| Story Objective | Not Applicable | Has deliverable upon completion, even if there is nothing to show at demo. If this is the case, do a verbal review, assuming audience is up for it. | Not Applicable |
| Story Points | No | Yes (aka Story Telling) | Yes |
