Story Points and Velocity in Ansible Projects with Scrum and Jira

Problem

In Scrum teams managing Ansible engineering projects, technical tasks and bugs are often treated as user stories and assigned story points. This distorts velocity metrics by including non-value-adding activities in the measurement of business value. For example, administrative or maintenance tasks get estimated like user stories, creating a false sense of productivity. As a result, velocity fails to accurately reflect the team’s ability to deliver automation content that benefits the organization, such as Ansible collections, roles, modules, inventory updates via GitOps, or improved documentation. Without a focus on business value, story points become ineffective, as they no longer represent meaningful progress toward organizational goals.

Context

Ansible projects often blend development, operations, and maintenance work. In a Scrum setup with Jira, teams use ticket types like user stories, bugs, and tasks. Refinement meetings are crucial for discussing and estimating all work types, including bugs and tasks, to ensure strong team understanding and planning. The core product in these projects is Ansible automation content, inventory, and documentation, which speed up lifecycle management, decouple operations, and automate admin tasks. Velocity should track progress in building this content, not unrelated technical chores or bug fixes, which can inflate metrics and create perverse incentives (e.g., more bugs seemingly increasing value).

This guideline targets teams new to automation, which often involves more than just automating lifecycle management (LCM) or maintenance—this aspect is frequently overlooked. It also requires shifting to DevOps, SRE, and an “automate-first” mindset. This is a significant change, including adopting software engineering discipline with iterative methods like Scrum. Organizations, projects, and teams often struggle to implement this effectively, as they deal with new concepts like distinguishing user stories, epics, tasks, and bugs. Without clear separations, planning gets complicated, and velocity fails to show productivity gains as teams build experience.

In contexts like the Dutch government, where experienced Ansible engineers are a scarce resource, teams are often transitioning and learning new skills. To maximize productivity, it’s advisable to have Ansible engineering teams focus as much as possible on engineering tasks, with separate operations teams or personnel handling operational tasks. For example, lifecycle management (LCM) and maintenance tasks using Ansible should be performed by Ansible operators, not engineers. Ansible engineers deliver content, inventory, and documentation, while separate operations teams use them. The engineers use an Ansible development environment to deliver these outputs, and this development environment is the only one they maintain and perform maintenance tasks on. All other environments are the responsibility of operations teams. This focus is essential for facilitating the learning process, which will increase productivity and engineering capacity by boosting velocity. As a consequence, the sprint board and backlog for Ansible engineers and teams should not include work related to other environments, except in rare, exceptional cases.

Solution

To measure velocity accurately and emphasize business value, adopt a strict approach to categorizing and estimating work in Jira for Ansible projects. Follow these steps:

1. Define the Product Clearly: Identify the core product as Ansible automation content (collections, modules, roles), inventory managed via GitOps as the single source of truth, and supporting documentation. Any work that doesn’t directly modify or enhance these should not be a user story.

2. Categorize Tickets Appropriately:

   • Use user stories only for items that deliver business value through changes to Ansible content, inventory, or documentation. Assign story points (SP) to these during refinement.
   • Use tasks for technical activities, administrative work, or support tasks (e.g., setting up pipelines, training, or bureaucracy) that don’t add to the core product.
   • Use bugs for fixes that maintain existing content but don’t expand it. Discuss bugs in refinement for planning impact, but do not assign SP.

3. Refinement Process:

   • Include all ticket types (user stories, bugs, tasks) in refinement meetings to assess overall sprint capacity.
   • Assign SP only to qualifying user stories. For bugs and tasks, estimate effort in hours or discuss qualitatively to inform planning without inflating velocity.

4. Planning and Velocity Tracking:

   • Base sprint planning on historical velocity from user stories only. Account for bugs and tasks by adjusting committed SP downward if they consume significant capacity.
   • Monitor velocity trends to reflect growing expertise (e.g., faster production of Ansible content over time).
   • Avoid steering solely by metrics; use common sense to evaluate if the work fits capacity, considering all elements.

5. Retrospective Integration: Conduct retrospectives to review these practices, making implicit choices explicit (e.g., acknowledging that velocity measures a mix if not strictly defined).

Benefits

• Accurate Business Value Measurement: Velocity reflects true productivity in delivering Ansible automation, helping track improvements like increased content production as teams gain experience.
• Better Planning and Capacity Management: By separating value-adding work from tasks/bugs, teams avoid overcommitting and gain clarity on impacts to sprints.
• Reduced Perverse Incentives: Prevents scenarios where introducing more bugs or bureaucracy artificially boosts metrics, encouraging focus on quality and efficiency.
• Improved Focus on Core Product: Ensures efforts prioritize Ansible content, inventory, and documentation, aligning with project goals.

Alternatives

One alternative is assigning SP to all work items, including bugs and tasks, to simplify tracking. However, this is not recommended as it mixes different types of value and distorts metrics. By default, Jira does not allow SP assignment to tasks and bugs, which aligns with best practices to avoid bad habits. Customizing Jira (e.g., modifying screens) to enable this requires extra effort and is a contentious decision—it essentially signals an organizational policy against focusing on business value. This should be frowned upon and not promoted, as it encourages teams to adopt practices that undermine accurate velocity tracking. Another approach is using Kanban for operations work alongside Scrum for development, but in blended projects, the strict categorization above provides a balanced hybrid without splitting boards.

Examples and Implementation

In a Jira setup for an Ansible project:

• User Story Example: “As an operator, I want an Ansible role for deploying SSSD with Active Directory integration so that authentication is automated.” Assign SP based on complexity (e.g., 5 SP). This directly enhances Ansible content.

• Task Example: “Investigate and document GitLab pipeline improvements for testing Ansible playbooks.” No SP; treat as a task that supports but doesn’t add to core content.

• Bug Example: “Fix error in existing Ansible module for package installation.” Discuss in refinement for time impact, but no SP; it maintains value without creating new.

File Structure Suggestion:

• Organize Jira epics around Ansible content themes (e.g., “Inventory GitOps”, “Role Development”).
• Use labels like “ansible-content” for user stories to filter velocity reports.

Implementation Tip: During sprint planning, review a burndown chart focused on user story SP, while noting task/bug hours separately. This ensures visibility into all work without skewing value metrics. For new teams starting Ansible projects, introduce this guideline in the first retrospective to set expectations.