Blog

Agile Development 2.0

The ServiceNow Agile Development 2.0 application provides an agile software development environment for product-based or project-based efforts, using the Scrum framework. It offers you the flexibility to implement a pure agile approach over the entire life-cycle of a product, or a hybrid approach using agile methods within a traditional project structure.

Activate

The only plugin you need to enable to use Agile Development 2.0 is “Agile Development 2.0”. However there are other plugins available that you may be interested in below.

  • Agile Development 2.0- main application

  • Agile Development Unified Backlog (optional) - Include items such as problems, incidents, enhancement requests, and other ServiceNow tasks into your Agile workflow, and work them just as you would work stories.

  • Project Portfolio Suite (optional) - to use the project workbench

  • Demand Management (optional) - to use demands

  • Agile Development 2.0 - ATF Tests (optional) - Agile Development 2.0 - ATF Tests provides you test cases and test suites that can be run on the Agile Development 2.0 application.

  • Performance Analytics Content Pack for Agile 2.0 (optional) - Agile Dev 2.0 dashboards for Teams, Sprints, Releases, and Epics.

These plugins are related to SAFe:

  • Agile - Scaled Agile Framework - Essential SAFe - Scaled Agile Framework was designed to apply Lean-Agile principles to the entire organization. Essential SAFe is most basic configuration of the framework and it provides the minimal elements necessary to be successful with SAFe: manage your agile release train backlog, plan program increments, implement stories, and track sprints.

  • Agile - Scaled Agile Framework - Essential SAFe - ATF Tests - provides you test cases and test suites that can be run on the Agile - Scaled Agile Framework - Essential SAFe application.

  • Agile - Scaled Agile Framework - Portfolio SAFe - Use Portfolio SAFe to apply lean and agile principles to your portfolio work.

  • Agile - Scaled Agile Framework - Unified Backlog - Include items such as problems, incidents, enhancement requests, and other ServiceNow tasks into your SAFe team workflow, and work them just as you would work stories.

  • Performance Analytics Content Pack for Essential SAFe - Essential SAFe dashboards for Teams, Sprints, Program Increments, Agile Release Trains, Features, and Epics.

You will need to activate the Agile Development plugin at a minimum to use the application.

Upgrades

If you are upgrading from an earlier ServiceNow release version of Agile Development to Agile Development 2.0, read upgrade information before activating the plugin.

DATA MODEL

Agile Development uses these tables to manage the agile process, represent releases, and represent product backlog items to be included in a sprint.

Agile Development Relationship Diagram

Also note that these SDLC Tables are also available:

  • Defect [rm_defect] - Represents a deviation from the expected behavior of a product.

  • Documentation Task [rm_doc] - Represents documentation tasks for the product.

  • Enhancement [rm_enhancement] - Represents an improvement to an existing product.

  • SDLC release [rm_release_sdlc] - Represents individual versions of the product.

  • Testing Task [rm_test] - Represents testing tasks for the product.

AGILE DEVELOPMENT IN ACTION

There potentially two types of development methods used within the Agile Development 2.0 application, Product-based and Project-based.

Different organizations follow different methods to deliver backlog/stories. However here are some example way you can use Agile Development

PRODUCT-BASED

  • A product can be a complete application or “thing” or a component of a larger product.

  • Led by a product owner

  • Long Term Approach

  • Occurs indefinitely during product lifespan

Task 1: Create a product

  1. A product is defined by a set of Features and functionality

  2. Stories created that identify the user, user’s goal, and reason for the goal.

  3. Stories make up the Product Backlog

  4. Product Owner prioritizes the stories

  5. Product Owner combines the highest priority stories into a release backlog

  6. Release Backlog is organized by themes and epics

  7. Product can have a narrow focus with few user stories or a wider context with many user stories, each containing several tasks.

  8. Maintain Product Backlog – Product owners maintain the product backlog. They continuously groom their backlogs by adding stories, prioritizing and estimating them.

Agile Board

Product

Task 2: Create an agile group

A group of type Agile Team can be created and group members can be added to it. For each group member, the default number of story points that a member completes in a sprint can be defined. At the group level, the sum of the group member story points determines the group capacity.

Task 3: Create a release AND TIMELINE

Some organizations have a fixed time frame to release stories or features, which is referred as a release. For example, a quarterly or six monthly releases. Releases are created by release or program management team and contain user stories, sometimes from multiple products that form the release backlog. A release has a start and end date during which several development iterations are completed.

Release

Task 4: Create a personalized backlog (OPTIONAL)

A personalized backlog can be created by defining filter criteria. For example, one personalized backlog can be a combination of stories, defects, and incidents while the other personalized backlog can be combination of stories and incidents. In a similar manner, you can create as many personalized backlogs as necessary.

Task 5: Create a sprint

A sprint is the time frame in which development team delivers one or more stories. A sprint can be of any length, but typically takes between one and four weeks to finish. The scrum master creates one or more sprints for the group. A release can have multiple sprints in it. All sprints within a release must fit within the release start and end dates.

The assignment group is expected to complete all stories to which it is committed within a sprint. At the same time, the group should also meet the acceptance criteria as defined in the story records. The scrum master expects that the stories are fully tested and potentially releasable. Usually, the committed stories for a specific sprint should not change during the sprint. However, the Agile Development application makes changes possible if necessary. Stories should be added or removed from a sprint only after a discussion with the group, scrum master, and product owner.

Task 6: Plan the sprint

Before a sprint starts, the group and scrum master decide on what stories from the backlog they can commit to complete within a sprint. The scrum master must make sure that the effort (story points) required to complete the stories matches the capacity of the group.

Stories for a sprint can be selected based on priority. To plan the sprint-related activities, use Sprint Planning.

A velocity chart is available to help in the estimation process. The velocity chart shows historical record for a group of the number of completed points, by sprint. This view gives the scrum master an idea of the general capacity of the group over time and produces more accurate sprint planning. Velocity charts are most meaningful when sprint duration and number of group members are constant. Use the velocity chart as guidance and not as a factual representation of what the group can produce in the next sprint.

Sprint Burndown

Sprint Burndown

Task 7: Track a sprint progress

The scrum master manages the sprint team efforts, provides progress reports, and removes any impediments that the team encounters. Team members update task and story records and conduct daily stand-up meetings (scrum meetings) to communicate their progress and concerns to the scrum master.

The scrum master can track the sprint progress using Sprint Tracking.

Task 8: Track a release progress

The product owner tracks the progress of the release.

Using the Analytics tab, product owner can verify whether the assignment group is completing stories and on track to achieve the release goal.

Task 9: REPEAT FOR EACH RELEASE

Continue completing releases to no end. Except when the value to the product added no longer justifies the cost.

Project-Based (PROJECT FIRST)

Project based agile development workflow example

  • Clearly defined scope and end date

  • Lead by a project manager

  • Incorporates agile based efforts into a traditional waterfall based project structure

  • Common because projects are typically funded as discrete projects

  • Requires PPM Application

TASK 1: DEMAND MANAGEMENT

Use the demand management application in ServiceNow to create and fund a project. This may use idea management to have users submit ideas, which in turn maybe become demands, which may be become projects.

TASK 2: CREATE PROJECT

Projects are created that include a mix of Stories, Sprints, and Project Tasks.

TASK 3: IMPLEMENT

Implement stories using Scrum Methods and complete project tasks using traditional workflow

Project-Based (STORIES FIRST)

  • Clearly defined scope and end date

  • Lead by a project manager

  • Incorporates agile based efforts into a traditional waterfall based project structure

  • Common because projects are typically funded as discrete projects

  • Requires PPM Application

TASK 1: COLLECT STORIES

Collect new requirements in the form of agile stories or enhancements over time. This might be from your service portal.

TASK 2: Relate Stories

Relate stories in a theme or in product backlog

TASK 2: DEMAND MANAGEMENT

Using the theme of product backlog, use the demand management application in ServiceNow to create and fund a project.

TASK 3: IMPLEMENT

Implement stories using Scrum Methods and complete project tasks using traditional workflow