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.
