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.
|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.|
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:
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.
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
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.
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.
OUPUT: Updated Backlog
Product Owner works with the Scrum team to define User Stories and prioritize the backlog for subsequent sprints.
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.
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:
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:
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.
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.
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.
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
Please see Unfinished Work section.
(PROJECT TEAM CODE) - “Sprint” (SPRINT NUMBER) - (UNIQUE NAME)
"ITSN - Sprint 14.10.1 - WAN Reports" (This would be the October 2014 Sprint from the ITSN Team)
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.
(PROJECT TEAM CODE) - “Release” (RELEASE NUMBER) - (UNIQUE NAME)
"ITSN - Release 14.10 - Split-Match" (This would be the October 2014 release from the ITSN Team)
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 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.
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.
Types of Tasks that we should see in each User Story:
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.
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:
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.
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