Overview
Note
As we move towards providing real-time performance analytics to our leadership to help drive better IT decisions, it is imperative that we begin to standardize processes around how we manage Agile projects.
This “SDLC” provides guidance to the entire TSD division on how the division operates in an “agile” environment. It covers the overall development lifecycle as well as standard operating proceedures for dealing with common issues that projects managers new to Agile Scrum tend to encounter.
It is an important objective of this guidance to be Agile in its own manner. This guidance is open to feedback and will be revised as our organization matures in its ability to manage agile projects.
Agile Scrum Terminology
| Term | Definition |
|---|---|
| Product Owner | The individual on the Scrum team who serves as the voice of the customer, and who has the authority to make decisions about the product or project being delivered. Owns the backlog. |
| ScrumMaster | Team leader responsible to help the team communicate and collaborate, to protect the team, to remove impediments, to mature the team, to coordinate outside the team, and to guide the team in following agile practices and principles. |
| User Story | A system requirement written from the point of view of the user or customer. Typically follows the format: “As a |
| Epic User Story | An Epic User Story is a requirement that is so large, that it must be broken down into smaller chunks that can be completed in a single sprint. |
| Initiative | An initiative is a grouping of features or User Stories that are planned out in releases. This can be roughly equated to a BCR or Business Capability Request. |
| Release | A deployable software package that is usually the culmination of several iteration cycles of incremental deliverables, and/or those iterations as a group. A release can be internal or external. |
| Sprint / Iteration | Block of time, typically one to four weeks long, in which a team plans, implements, and delivers a set of functionality. |
Scrum Team Charter
All TSD DM&E Projects that are utilizing the Agile SCRUM development methodology must create an Agile SCRUM Charter that is approved by a TSD Division Branch Chief. The Charter is an extremely important document for all agile teams and serves as the basis for how the entire project is run.
Note: Work with your Supervisor
Your Agile Scrum Team Charter must be approved by a TSD Division Branch Chief. First and foremost, the charter is a tool for the Scrum team to define the most basic elements of how the team will organize. This is extremely important for teams that are new to the agile process and may not be familiar with all of the basic concepts like sprint cadence and definition of done. The charter also assists leadership in understanding expected team velocity and capacity.
Lastly, the charter serves as a basis of understanding between the Product Owner and scrum team. This is extremely important for having a common understanding of User Acceptance Testing (UAT), as it is the number one contributor to work-in-progress loops, and blockers.
The Scrum team charter includes the following:
- Team Definition
- Scrum Team / Developer(s)
- SCRUM Master
- Business Owner(s)
- Sprint and Release Cadences
- Definition of Done
- Production Release Schedule
- User Acceptance Testing (UAT) Plan
Standard Milestones and Gates
Release Planning
INPUT: Backlog / Business Requirements Document (BRD)
OUPUT: Product Owner Approved Release Plan
Performed at the beginning of the Release cycle, Product Owners work with the Scrum team to determine Initiatives and Features to be released.
Sprint Planning
INPUT: Backlog / BRD and Release Plan
OUPUT: ScrumMaster Approved Sprint Plan
Product Owner(s) work with Scrum team to plan out individual user stories to be tackled during the sprint
Demo/UAT
INPUT: Completed User Stories
OUPUT: Business Owner User Story Acceptance
Scrum team shows Product Owner(s) completed work and receives feedback that is used to create new User Stories as well as defects. Once Demo/UAT is completed, the Scrum team has their approval to promote accepted work to production.
Retrospective
INPUT: Completed Sprint
OUPUT: Architectural User Stories
The Scrum team reviews the activities during the previous sprint and develop architectural user stories that help improve availability, predictability, scalability, etc… to meet the customer need.
Backlog Grooming
INPUT: Backlog
OUPUT: Updated Backlog
Product Owner works with the Scrum team to define User Stories and prioritize the backlog for subsequent sprints.
Roles and Responsibilities
Every Scrum team has three roles: product owner, ScrumMaster, and development team. The individuals in these roles work together to bring a product from an idea to life.
Product Owner
The product owner is the member of the Scrum team charged with maximizing the value of the team’s work. The product owner holds the product vision and works closely with stakeholders, such as end users, customers, and the business to cultivate and nurture a community around the product. They facilitate communication between the team and the stakeholders and ensure the team is building the right product. They describe what should be built and why, but not how.
To fulfill the role, the product owner:
- Decides what goes into the product backlog and, equally important, what does not
- Maintains the product backlog and orders the items in the backlog to deliver the highest value
- Works with the team and the stakeholders to continuously improve the quality of the product backlog and everyone’s understanding of the items it contains
- Decides which product backlog items to ask the team deliver in the current sprint
- Decides when to ship the product, with a preference toward more frequent delivery.
- The product owner may be supported by other individuals but must be a single person to maintain clarity of the vision and priorities.
ScrumMaster
The ScrumMaster is a servant leader, helping the rest of the Scrum team progress. The ScrumMaster keeps the Scrum team productive and learning. They must have a good understanding of the Scrum framework and the ability to train others to use it. The ScrumMaster has three core responsibilities:
Coach the team
The ScrumMaster helps the entire team perform better. They help the product owner understand how to create and maintain the product backlog so the project is well defined and work flows smoothly to the team. They also work with the whole Scrum team to determine the definition of done. The ScrumMaster coaches the team on how to execute the Scrum process, helping them learn and use the framework and find and implement technical practices so they can reach done at the end of each sprint.
Keep the team moving forward
As a servant leader, the ScrumMaster fosters the team’s self-organization and then sees that distractions and impediments, or roadblocks, to the team’s progress are removed. Impediments may be external to the team, like lack of support from another team, or they could be internal, like the product owner not knowing how to prepare a proper product backlog. They may also facilitate regular team meetings to ensure that the team progresses on its path to done.
Help everyone understand Scrum
The ScrumMaster ensures that Scrum is understood and in place, both inside and outside the team. They help people outside the team understand the process, as well as which interactions with the team are helpful and which are not. The ScrumMaster helps everyone improve to make the Scrum team more productive and valuable.
Development team member
The development team does the actual work of delivering the product increment. The team is a cross-functional group of professionals who, among them, have all the necessary skills to deliver each increment of the product. All team members should be available to the team and the project full time.
The product owner makes an ordered list of what needs to be done. The development team members then forecast how much they can do in one sprint and self-organize to get the work done, deciding among themselves who does what to produce the new product increment. - See more at: https://www.scrumalliance.org/why-scrum/core-scrum-values-roles#sthash.oB2Kpf8C.dpuf
Sprint Management
- Each sprint must be baselined prior to starting. This means that all user story definitions and planning must be done prior to the sprint starting. It is a responsibility of the TSD PM to ensure that the Sprint is planned and started on time.
- Sprints must have one of the following cadences:
- Monthly sprint – Starts on the first day of the Month and ends on the last day.
- Twice a month sprint - This includes 2 equal length sprints that are performed in a single month. Sprint 1: 1st – 15th of a month, Sprint 2: 16nd – 30th of a month
- Sprints must align to a Release.
- Sprints may be re-baselined, but must not break normal time-box. So if a re-baseline is performed mid-sprint, the re-baselined sprint can only be a half-sprint long.
- Team member capacity must be determined during sprint planning. Team member capacity should be based upon 85% of committed work hours.
- Team members should not be assigned more that 100% of their available capacity.
- Sprint re-baselining must be approved by the Business owner and TSD Branch Chief.
Managing Unfinshed Work
Please see Unfinished Work section.
Sprint Naming Conventions
(PROJECT TEAM CODE) - “Sprint” (SPRINT NUMBER) - (UNIQUE NAME)
- Project Team Code: Should be the short name or acronym for your project team. Examples include “AcQNav”, “ITSN”, and “FAaaST.”
- Sprint Number: The Sprint Number refers to the Calendar year, month, and “part” of the sprint. For example, if your doing twice monthly sprints and this is the second sprint of the of October 2014, the release number would be 14.10.2. Sprint Number is prefixed with the word “sprint” for reporting purposes to prevent confusion with Releases.
- Unique Name: This can be any text to help the teams better define a Release. It is not required.
Example:
"ITSN - Sprint 14.10.1 - WAN Reports" (This would be the October 2014 Sprint from the ITSN Team)
Release Management
A release is a deployable software package that is usually the culmination of several iteration cycles of incremental deliverables, and/or those iterations as a group. A release can be internal or external.
General Guidance
- Each release must be baselined prior to starting. This means that all features, themes, initiatives, and/or program epics must be defined prior to the start of the release. It is a responsibility of the TSD PM to ensure that the release is planned and started on time.
- All releases should follow a cadence that maps to a calendar month. Starting on the first day of a month, and ending on the last day of that or a subsequent month.
- Regular releases may not be longer than 3 months, and should not be shorter than 1 month.
- Regular releases occur off hours and outside of normal sprint planning.
- Releases should be named based upon the calendar month of the release. Features must be assigned to release.
- User Stories must be at least defined in order to place in a release.
Naming Conventions
(PROJECT TEAM CODE) - “Release” (RELEASE NUMBER) - (UNIQUE NAME)
- Project Team Code: Should be the short name or acronym for your project team. Examples include “AcQNav”, “ITSN”, and “FAaaST.”
- Release Number: The Release Number refers to the Calendar Month and year of the last month of the release cycle. For example, if your doing a quarterly release for the 1st calendar quarter in 2014, the release number would be 14.3. 3 refers to March, which is the last month in the release cycle. Release Number is prefixed with the word “release” for reporting purposes to prevent confusion with sprints..
- Unique Name: This can be any text to help the teams better define a Release. It is not required
Example:
"ITSN - Release 14.10 - Split-Match" (This would be the October 2014 release from the ITSN Team)
User Story Management
In software development and product management, a user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job functio
- User stories must follow the “As A….I need….So I can….” format, and equate to some form of some sort of delivered business value. This includes “Architectural backlog” User Stories.
- User stories must be sized (“points”) based upon relative sizing using the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc…)
- Stale User Stories (3+ releases old) should be re-validated with the business as well as technical team prior to being scheduled
- All user stories must link to a defined Portfolio Management “Feature”. User Stories that are not completed during a normal sprint must be split. This means that a parent User Story is created, and unfinished work is placed in a new child User Story that is planned in the subsequent sprint.
User Story Approvals
- Only Product Owners may create user stories.
- Only Product Owners my “Cancel” a user story.
- Only Product Owners may “Accept” a user story.
- Only Product Owners may “re-open” a cancelled user story.
Example of a Defined User Story
User Story: As a Financial Analyst, I need a report summarizing customer agency business volume with taxes and surcharges so I can reconcile those numbers against pegasys and validate vendor CAF payments.
Acceptance Criteria
- A new Webi report titled “Summary by Agency of Business Volume w/Taxes Surcharges report” available in Business Objects
- The report should include the following fields:
- Agency Code
- Agency Name
- Invoice Date - Fiscal Year
- BV with Taxes
- The report should have a prompt to select a single fiscal year
- Format needs to be a cross-tab
- Data validation against access database
- Report format should match the attached WAN report format provided by ITS
Rally Tip:
Attach any requirements, screen shots, customer feedback, email, picture, or other files related to a User Story directly to the User Story in Rally to provide better traceability and ease of access.
User Story States
Task Management
- Tasks should be no longer than 8 hours in length. If a task is estimated to take longer than 8 hours, it needs to be broken up into small sub tasks. E.g. A large program document such as an System Security Plan can be broken up several tasks related to the sections of the document, or the collection of information to populate the document.
- Tasks are assigned to a single team member.
- Each task should include an estimate of hours, and hours remaining. The estimate of hours does not change, but time remaining can be reduced or increased.
Types of Tasks that we should see in each User Story:
- Fortify Scans,
- SSP Updates,
- Test Case Development and Execution
- 508 Scans
- Subversion check-in
Portfolio Management
Initiative: Project or Requirement that expands multiple SCRUM Teams or multiple releases. Synonymous with Business Capability Request (BCR).
Feature: Requirement that can be completed by a single SCRUM team during a single release.
Examples:
- INITIATIVE (TSD): ITS WAN
- FEATURE (CAP/EDW): WAN EDW Data Ingest
- FEATURE (EIM/AaaS): WAN Dashboards and Reporting
- INIATIVE (TSD): EULA
- FEATURE (CAP/EDW): EULA Metadata Storage and Processing
- FEATURE (EIM/ECMS): EULA File Storage and Retreival
- FEATURE (EIM/eSOA): EULA Virtual Web Services / API
- FEATURE (CES/TBD) : Search Engine Interface
Managing Unfinished Work
One of the most common problems that teams run into is handling unfinished work. Whether it is defects, scope creep, or technical debt, the team finds itself unable to complete everything it was attempting to do.
Note: UNDER NO CIRCUMSTANCES IS A TEAM TO EXTEND A SPRINT/TIME BOX’s END DATE
There are 2 options in handling unfinished work:
Moving
In this scenario, The user story in its entierty is moved to the following sprint. The work that is completed still remains complete. The advantage of this approach is purely that it is easier than moving, it does however count against the teams velocity.
Splitting
In this scenario, the team is still able to provide some value to the business with the work that was completed. The Scrum master literally splits the user story into smaller user stories, and moves unfinished work either to a subsequent sprint, or the backlog.
An Epic user story must be created to link the user stories together.
The advantage of this approach is that the team still claims velocity as well as delivering user value. It is however, a more complex process.
Note: Only the Scrum master should perform user story splitting