ServiceNow Agile Development manages Scrum or waterfall development efforts and defines the tasks required for developing and maintaining software throughout the lifecycle, from inception, through testing, to deployment.
Many companies today have different applications for tracking this work. Often it doesn't make sense to use those other tools when ServiceNow includes Agile Development in the base package. Plus ServiceNow Agile Development is readily connected to the Service Portal, Incident Management, and other ServiceNow applications.
Agile Development can bring all of these other tools, workflows, and more importantly licenses together in a single system of record.
ActiVATE
These plugins are related to Agile Development in ServiceNow:
- Agile Development - main application
- Context Ranking - required for usage of Agile Development
- NG shared components - required for usage of Agile Development
- Custom Charts - required for usage of Agile Development
- Model Management - required for usage of Agile Development
- SDLC - SCRUM - Likely preinstalled. Required for usage of Agile Development
- Software Development Lifecycle SDLC - Likely preinstalled. Required for usage of Agile Development
- Project Portfolio Suite (optional) - to use the project workbench
- Demand Management (optional) - to use demands
You will need to activate the Agile Development plugin at a minimum to use the application.
OPEN FOR YOUR PROCESS
You can use the Agile Development application in anyway you choose. It is an open application in which you can conduct your releases in a waterfall or agile approach. Or you can do what many companies do, and use a hybrid agile/waterfall approach. The "Agile Development" application does lead itself towards Agile, hence the name. No matter what you choose, it is a starting point for whatever software development method you want.
In this article however, I will talk about the application in terms of Agile.
THE SCRUM FRAMEWORK
Daily scrum
The scrum master meets briefly with team members each day to discuss progress, planned work, and any impediments (known as blockers).
Blocked Story
Scrum Release
Product Backlog
The product owner creates and maintains a product backlog, which is a collection of user stories captured within a scrum product. A product represents a development target of related functionality that is composed of themes, epics, and stories. A product owner typically ranks the stories in a product backlog by order of importance.
Product Backlog
Release Backlog
A release is a time frame in which a number of development iterations are completed. The product owner collaborates with the scrum master to determine which stories should be targeted for a release. Stories from one or more products can be targeted to a release. Typically, the decision process is based on the release timescale, the story rank within the product backlog, and the story complexity. Other criteria can be used depending on the nature of the project. The targeted stories form the release backlog. Stories in the release backlog are targeted to a release, but have not yet been associated with a sprint. Throughout the release, the release backlog shrinks as stories are moved into sprints. As this occurs, the product owner can see what remains to be completed.
Visual Task Board: Stories By Release
Sprint Backlog
The sprint backlog is a list of stories the sprint team members have agreed to complete for a sprint. During sprint planning, the scrum master collaborates with the scrum team to decide which stories they can commit to delivering in the sprint. Typically, they commit to the top ranked stories first. The team decides what scrum tasks are necessary for each story. The product owner should be present to answer any questions.
Sprint Planning Board
Sprints
Team members work to complete stories in the current sprint backlog. Team progress is tracked during daily stand-up meetings in which members discuss the work completed the previous day, the planned work for the next day, and any blocking issues. The scrum master keeps the team members focused on completing the stories in the current sprint and tries to remove any impediments they face. At the end of the sprint, all the stories should be complete. Any incomplete stories are moved into an appropriate backlog. A review meeting at the end of the sprint, known as a retrospective, allows team members to discuss what went well and what did not, with the goal of improving future sprints.
Burndown Chart
Sprint Review and Retrospectives
At the end of the sprint, the scrum master and team members discuss the work completed and demonstrate new features.
Also at the end of the sprint, the scrum master and team members discuss the work completed and demonstrate the completed work to the product owner. In addition, the team reviews the sprint and discusses ways to improve the execution of future sprints.
Sprint planning
The next sprint begins with the team importing stories from the release backlog into the sprint backlog. The scrum master and team members select the stories that they can commit to deliver during a sprint.
Enhancements and Defects
Users with a special, non-scrum role can create enhancement and defects within the Agile Development application.
A scrum product owner reviews these requests and decides whether or not to create one or more user stories. Scrum users with the proper roles can edit and manage the stories and their backlogs from the Stories related list in the Enhancements form. A user without scrum roles who submits an enhancement request cannot see other Agile Development modules or the stories attached to the enhancement request.
Enhancement
Defect
More Information
Read more about Agile Development: