Skip to main content

Agile Process

The agile methodology for projects is an iterative cyclical process of defining user stories, coding and development, testing, product delivery and feedback.

As with any methodology, there are advantages and disadvantages to the agile process. The Agile method is most suitable for time & material structured projects where customers and project stakeholders are available to provide input, functional portions of software are needed quickly, flexibility is desired to accommodate changing requirements, and the team is able to effectively collaborate.

The hierarchy of work items in DevOps for the Agile process looks like this:

agile devops workflow

Real world example​

agile devops workflow

User Stories​

Workflow & Life-cycle​

The User Story work item represents a functional increment of work to be completed. Ideally, all known core system requirements and desired user interaction and system behavior scenarios should be entered into the project backlog as user stories at the onset of the project by the Product Owner.

Since user stories are the most used work item, let's break down their life-cycle and how they move through the kanban board. Then we'll briefly cover the other work items.

workflow

  1. "New" status - user stories are added to the backlog with an initial status of New by the product owner. User stories don't need to have many details at this point other than the title. Additional details will be added to them as detailed requirements and use cases are completed. The title should be written as a simplified summary of the desired functionality (using sentence case). Example: Export data to CSV. Each story should also create a story description written using the following 3-part formula:
agile devops workflow

Note: "user" can be modified to match the end user in the title - "user”, “administrator”, “editor”

Next Steps: Additional details are added to the user stories as the requirements and use cases are completed. During scrum planning meetings the priority of user stories should be discussed and updated by the Product Owner. The scrum master will then move user stories to the "Active" status and assign to a developer based on priority.

  1. "Active" status – user stories are moved to active status and assigned to a developer in the planning meeting based on priority. Tasks are created for the user story as needed to cover individual development work items and needed supporting artifacts such as wireframes, test cases, etc. Creating a PR moves it to the Ready to Test status.

  2. "Ready to Test" status – once moved to the Ready to Test status, the user story undergoes a process of approval where it must be approved by the appropriate reviewers, the Product Owner, QA tester and UX Specialist are "required approver" roles and the user story must be approved by each before it is moved to Closed.

  3. "Closed" status – once the user story is approved by all "required approvers" it is moved to Closed.

Priority​

Used to rate order of importance for user stories.

  • 1=CRITICAL Product cannot ship without the successful resolution of the work item, and it should be addressed as soon as possible.
  • 2=HIGH Product cannot ship without the successful resolution of the work item, but it does not need to be addressed immediately.
  • 3=MEDIUM Product can ship without the successful resolution of the work item, but it should be a high priority for the next shipment/iteration.
  • 4=LOW Resolution of the work item is optional based on resources, time, and risk.

Story Points​

Used to determine the relative size and complexity for implementation of a user story.

Ideally, we want to extract the real requirements needed to complete each user story and break the work into tasks that can be delivered in 2-3 days. The smaller the effort needed to complete a user story the better we can provide realistic delivery estimates and measure velocity.

Before assigning story points of 8+ during a planning meeting, seriously consider the benefit of slicing the user story into smaller, separate stories. A max of 21 user story points can be assigned.

Complexity is not linear, therefore a Fibonacci scale is used to measure story points:

  • 0 – minimal time (example: fixing a typo). Should be used sparingly as it will offer no velocity credit.
  • 1
  • 2
  • 3
  • 5
  • 8
  • 13
  • 21 – largest amount of work. Should consider breaking into smaller stories.

Acceptance Criteria​

Each User Story must include a well-defined acceptance criteria. This acceptance criteria defines exactly what must be in place for this functionality to be considered done.

Epics​

The Epic work item represents a large “chunk” of work or a business initiative to be accomplished. Typically an epic will span many sprints. For example:

  • Multi-language support
  • Intersection editing
  • External integrations

Epics can be added at the beginning of a project or user stories can be organized into Epics as the project is implemented based on the project work plan and delivery milestones.

Features​

The Feature work item represents a single shippable component of software. For example:

  • Map interface for discovery and visualization of intersections
  • Ability to query routes using text search
  • Ability to send email notifications from the SLD

Similar to Epics above, Features can be added at the beginning of a project or user stories can be organized into Features as the project is implemented based on the project work plan and delivery milestones.

Tasks​

The Task work item tracks the individual elements of work needed to support the completion/implementation of a user story. For example:

  • Add standard navigation tools
  • Add basemap widget
  • Add a content panel for map display

Tasks are created and added to "Active" user stories as needed to complete user story implementation. See User Story Life-Cycle above.

Before a task is started, it should be estimated and the Original Estimate value should be entered. As the task progresses, the Remaining and Completed fields should be updated. These tasks provide analytics to help managers equate a story point to number of hours. Additionally, these hours help pinpoint a resources story point to hours ratio which helps with planning and delivery estimates.

Bugs & Issues​

The Bug work item records a defect with the product and is related to a specific user story.

The Issue work item tracks unplanned activities and impediments that may impact the completion of meeting user story requirements in the planned scope.

Resources​

Training Material​

The following video was internal Rizing Geospatial training session on introduction to Agile, Scrum, and Azure DevOps.

Making Agile Work for Your Team​

If you are new to the process, below are four activities that will help support the adoption of an Agile workflow:

  • Daily Meetings - Host consistent or daily stand-up meetings to maintain open communication and keep each iteration moving forward
  • Live Demonstrations - Deliver live demonstrations of each iteration’s final product to show progress
  • Share Feedback - Receive feedback from stakeholders and customers and share it with the entire team before the next iteration begins
  • Remain Agile - Make changes to your process based on feedback to ensure each iteration improves the last

Summary and Standards​

Roles​

Product Owner​

  • Translates stakeholder requirements to User Stories
  • Ensures User Stories have well-defined Acceptance Criteria
  • Ensures proper details and determines priority

SCRUM Master​

  • Runs daily standups and other rituals
  • Removes blockers
  • Keeps things moving forward

Work Item Naming Conventions​

  • Epic: Sentence case (ex: "Multi-language support")
  • Feature: Sentence case (ex: "Spanish locale")
  • User Story: Sentence case (ex: "App text in Spanish")
  • Task: Sentence case (ex: "Implement locale switching")

agile devops workflow

User Stories​

  • A story should always include a description in the format of "As a [typeof user], I want [some feature] so that [some reason]
  • Once a User Story is assigned to someone it is their responsibility to see the story through to completion
  • One a story is assigned to someone, it is their responsibility to break it up into smaller tasks
  • Create User Stories as if the person doing the work has no clue what you are talking about - because chances are they don't
  • A story's status must be kept up to date:
    • New: not currently being worked on
    • Active: work has started on this story
    • Resolve: work is complete and undergoing testing (a PR is created)
    • CLosed: work has passed acceptance criteria (PR has been merged)

Story Points​

  • 0, 1, 2, 3, 5, 8, 13, 21

Tasks​

  • When creating a task, hours must be tracked within the task's "Effort" section.

General Workflow​

1) Sprint planning meeting​

  • Everyone: Stories are reviewed
  • Everyone: Agrees on scope and story points
  • SCRUM Master: Assigns User Story to development team member

2) Team member starts work on story​

  • Team member breaks story into smaller tasks
  • Team member estimates each task
  • Team member updates task hours as they progress
  • Team member updates feature/story/task details as they progress
  • Team member communicates through the appropriate communication channels

3) Daily standup​

  • SCRUM master facilitates meeting
    • ensure each member has no more than 2 minutes
    • ensures the meeting stays in scope
    • facilitates efforts to remove blockers
  • Each team member reports:
    • what they worked on yesterday
    • what they are working on today
    • do they have any blockers

4) Team member finishes story​

  • Marks any relevant work items as Resolved
  • Creates a Pull Request (PR)
  • Ensures PR has all necessary details and work item links
  • Sets the PR to Auto Complete
  • Constantly watches the PR to address any reported issues

5) Testing​

  • The entire team reviews the PR
    • Development team is checking code quality
    • Product owner and testers are checking functionality
  • Everyone Approves the PR once they are satisfied
  • Once all approvers have approved, the PR will be merged
  • The PR creator ensure that the related work items are marked as Closed

Repeat...

Communication Channels​

  • Communication on specific work items (feature, story, task, etc.) should happen as comments within the work item
    • This will keep all relevant communication and decisions made with the "requirements"
  • When reviewing a PR comments should be added to the PR
    • Communication should be very clear
    • When adding a comment to a PR, if there is not an action item you must mark the comment as closed so that it doesn't block the PR from being merged.
  • All other general communication should go through the Team's channel