Doing Agile the right way: Points and the contract.

Beyond the Numbers: Understanding Story Points as a Tacit Contract in Azure DevOps: Embracing Observability & SecDevOps

Introduction: Setting the Stage

Let's be honest: the idea of "story points" can feel a bit…well, absurd at first. It’s like trying to measure the feeling of a good cup of coffee with a ruler. But story points aren’t about precise measurement. They're a tool for communication, collaboration, and crucially, understanding the relative complexity of tasks. But, if we're doing them right, they're not about measuring time; they're about making a promise. A tacit one, mind you, the kind you make with a knowing glance and a slightly uncomfortable shrug. They’re about estimating the effort, not the time. Using story points allows us to prioritize effectively and track our velocity: essentially, how quickly we're moving forward. It’s a surprisingly useful approach, and it’s a cornerstone of DevSecOps.

The Interconnected Ecosystem: Observability & SecDevOps

Imagine a chaotic orchestra where everyone is playing different instruments, and no one knows what the others are doing. That’s what development can be without a good system. Azure DevOps, however, is like a beautifully orchestrated symphony. Azure Boards (for planning), Azure Repos (for code), Azure Pipelines (for builds and deployments), and Azure Artifacts (for managing packages): they all talk to each other. Changes in the plan are immediately reflected in the code, builds, and deployments. This creates a feedback loop: a crucial element for observability.

Think of it this way: a small bug introduced during a build is immediately flagged, and the team can quickly roll back the changes. This is a fundamental principle of SecDevOps: proactive security, continuous monitoring, and rapid response. Without this integration, you’re basically flying blind. It’s like trying to fix a leaky pipe, but this time with a flashlight. Real-time visibility is key!

Observability and SecDevOps: Keeping the Contract Alive

Without observability, the ability to understand what's going on inside your system, that tacit contract is fragile. You need to know why things are happening. Monitoring, logging, and tracing are your friends. SecDevOps practices aren't just about adding security; they're about building resilience and understanding. As much about how we work than what we deliver!

So, what's a User Story Anyway? (And Why It's a Secret Agreement)

A user story, at its heart, is a little snippet of a conversation. It's not a detailed specification document. It's not a blueprint. It's a starting point. A good one looks something like this: "As a [user role], I want [goal] so that [benefit]." Example: "As a customer, I want to be able to reset my password, so that I can access my account if I forget it." Simple, right?
But here's the thing: it's not just the words. It's the implicit agreement that follows. That's where the "tacit" part comes in. It's like agreeing to meet for coffee, you don't write down the exact route, the temperature, or the preferred brand of coffee. You just agree to meet. And then, you figure it out. A well-crafted user story is the basis of that agreement.

The Art of Less Stress, More Promise

Agile documentation, and I'm not talking about a 100-page binder, I mean oll the stuff we just put in our workboards, is actually about reducing the pressure on the team. Let's be real, constantly chasing the elusive "perfect spec just breeds anxiety. It's a game of endless refinement, and honestly, it's exhausting. By focusing on a lightweight approach, you shift the emphasis from meticulously documenting every single detail to simply capturing enough information to keep everyone aligned. It's about shared understanding, not a rigid contract.

The Parts That "Lock In" the Specification (and Why You Shouldn't Ignore Them)

Let's break down what makes a user story actually stick. It's more than just the basic format. Here's what needs to be there to ensure everyone is on the same page, and to create that powerful, unspoken contract:

• Acceptance Criteria: These are the rules of the agreement. They're the things that have to be true for the story to be considered "done.” They're not optional. Example: "Given I've entered a valid email address, when I click ‘Reset Password,' then I should receive an email with a link to reset my password.”
• Definition of Done (DoD): This is the broader checklist, security scans, code reviews, integration tests, etc. It's what ensures the story is truly complete and reliable.
• Business Value: This is the "so that..." part. It's why we're doing this. It's the link to the business goal. Without it, you're just building shiny objects.
• Technical Considerations: Sometimes, the team needs to discuss technical implications. This isn't necessarily part of the user story, but it's important to acknowledge it.

Story Points: Commitments, Not Timelines

Forget about trying to map story points to hours. That's a recipe for frustration. Story points are relative estimates, are we talking a "small tweak” or a "major overhaul”? Think of them as a way to communicate relative complexity and risk. Again, we’re not trying to quantify effort (that’s a trap!). We’re trying to establish a relative measure of complexity and risk. A story that’s roughly equivalent to 8 points is roughly as complex as a story that’s 13 points. The point isn’t the number itself, it’s the shared understanding it represents.

The 13-Point Rule: When to Break It Down

Here's a little secret: anything estimated at 13 or above should probably be broken down. Seriously. It's a red flag. A big, flashing warning sign that you're about to embark on something potentially hairy. Large stories are often a symptom of scope creep or a lack of clarity.

Think of it this way: If you're estimating a story at 13, you're essentially saying, "I'm not entirely sure what I'm getting into here." That's okay! But it needs to be addressed. Don't just throw it at a developer and hope for the best.

The Fibonacci Sequence: Why Relative Scale?

You’ve probably heard the story of Ron Jeffries and the Fibonacci sequence. He was trying to estimate the effort on a project, and he realized that tasks often fall into distinct categories: some are tiny, some are huge. The sequence (1, 2, 3, 5, 8, 13…) is a natural way to represent this. It’s like saying, "Okay, this task is roughly the size of a small dog, this one is the size of a golden retriever…" 

The Value of a Point: Scale, Not Absolutes

Don’t fall into the trap of thinking that a "3" always means the same thing. In Sprint 1, a "3" might be a huge undertaking: rewriting a significant portion of the application. But by Sprint 5, it’s likely to be a standard task. The value of a point solidifies over time as the team gains experience and shared understanding. It's about tracking velocity: the trend of how quickly you’re moving forward, not a rigid target. Think of it like this: a seasoned marathon runner knows their pace better than a beginner.

Rigor and Flexibility: Finding the Balance

While it's important to be thoughtful about our estimates, don’t get bogged down in the details. Rigor and flexibility must be balanced. Use techniques like sprint retrospectives and planning poker to refine your estimates over time. Embrace self-organization and adaptation. Remember, the goal is to communicate effectively and deliver value.

Azure Boards, Repos, Pipelines, Artifacts: Building the "Teeth”

This is where the magic happens. When you connect your Azure Boards, your Git Repos, your Pipelines, and your Artifacts, you're building the teeth into that tacit contract.

• Azure Boards: Provides the framework for the story, the backlog, and the sprint planning.
• Repos: The source of truth for the code.
• Pipelines: Automate the build, test, and deployment process, ensuring consistent delivery.
• Artifacts: The packaged deliverable, ready to be deployed.

This integrated ecosystem turns a vague promise into a concrete, verifiable outcome. Security and DevOps (SecDevOps) practices are crucial here. Think automated security scans in your pipelines, vulnerability assessments, and continuous monitoring.

Conclusion

TLDR; Story points aren't about measuring time. They're about building trust, fostering collaboration, and turning vague intentions into concrete outcomes. By connecting your tools and embracing SecDevOps, you can transform your agile process from a series of guesses into a reliable, repeatable delivery pipeline.

And ultimately, story points are a tool for communication and collaboration, not a rigid measurement system. Embrace the "tacit contract" approach: focus on shared understanding, and let the numbers guide you. Don’t get hung up on the numbers; focus on delivering value.

Ready to transform your DevSecOps practices? Leave us a comment below, to schedule a consultation and learn how we can help you build a more effective and collaborative team.

Coming up next: SecDevOps and Platform Engineering.