DEV Community

Cover image for More Than Just a Board: Why My First Jira Sprint Was a Lesson in DevOps
Goodness Ojonuba
Goodness Ojonuba

Posted on

More Than Just a Board: Why My First Jira Sprint Was a Lesson in DevOps

Introduction
Before this sprint, Jira felt like a task board where you move tasks/stories around. After running a full sprint myself, I realized Jira is really about visibility, rhythm, and learning, not just tracking work.

In this sprint, I planned work, ran daily updates, shipped a small UI improvement, tracked progress using the burndown chart, and closed the sprint with a retrospective.
That process changed how I think about delivery.
Jira board

The Daily Scrum: Small Updates, Big Clarity
The Daily Scrum looked simple at first. Just three questions:

  • What did I do yesterday?
  • What will I do today?
  • What is blocking me?

But writing these updates every day forced me to think about progress in small increments, not big unfinished work.

Even working solo, the daily update created accountability. Each day needed a visible outcome, not just effort.

This naturally led to shipping smaller improvements more consistently.

Jira story showing Daily Scrum comments

Backlog Refinement Made Sprint Planning Easier
Before the sprint started, I created stories, added acceptance criteria, estimated them, and ranked them by value.

This step made sprint planning much easier because:

  • The work was already clear
  • Stories were small and understandable
  • Scope decisions were simpler Without backlog refinement, sprint planning would have felt like guessing.

Backlog view showing Epic and story with story points

Sprint Planning: Turning Ideas into Commitment
Sprint planning was where the work became real.

Instead of selecting everything, I chose just a few stories that could realistically be completed within the sprint.

That decision matters. A sprint is not a to-do list. It is a commitment to deliver a usable increment.

Once Sprint 1 started, the goal was simple: Ship 2–3 visible UI improvements to Gotto Job and show them live.

Sprint 1 showing selected story

The Burndown Chart: Seeing Progress Visually
The burndown chart showed sprint progress over time. Even with a small sprint, it made progress visible in a way the board alone could not.

It answered an important question: Are we moving toward finishing the sprint goal?

Instead of relying on memory or assumptions, the chart provided objective feedback about delivery progress.

That transparency is what makes Scrum effective.

Burndown Chart

work stats

Sprint Burndown chart

Shipping One Increment (The DevOps Moment)
During the sprint, I implemented one UI improvement, committed the change, deployed it, and verified it on the live site.

That single cycle represented the DevOps lifecycle in practice: Plan → Build → Deploy → Verify

For this project I ship one small change at a time and the first was the Tagline changed to meet the Acceptance Criteria

Tagline Before Update:Tagline Before Update:
Tagline After Update:Tagline After Update:

Shipping one small improvement felt more valuable than working on many unfinished changes.

Why the Retro Is the Most Valuable Part
The retrospective is where the sprint turns into learning.

Instead of asking “Did we finish tasks?”, the retrospective asks:

  • What went well?
  • What should improve?
  • What should we try next sprint?

This is where continuous improvement happens.

For example, in my sprint, the retrospective captured these reflections:

  • What went well: The Git-to-deployment workflow was smooth, and the hero tagline update was successfully delivered and verified on the live site. Working in solo mode helped me stay organized and maintain clear ownership of the sprint tasks.
  • What to improve: Automate EC2 deployment using user-data or scripts to reduce manual deployment time and improve consistency.
  • Scrum Pillar – Inspection: I practiced inspection by verifying changes locally and on the live URL to ensure the UI updates met the acceptance criteria before closing the story.
  • Scrum Value – Commitment: I stayed committed to completing one story at a time and delivering a working increment during the sprint.

Retro Note

Final Reflection

Running a sprint showed me that Jira is not the important part. The important part is the workflow around it.

Daily Scrum builds consistency. Burndown charts create transparency. Retrospectives create improvement.

Together, they turn work into a repeatable delivery system.

That was my biggest takeaway from running my first Jira sprint.

P.S. If you're starting your DevOps journey, you can join the DevOps Micro Internship (DMI) community led by Pravin Mishra on Discord.It’s a great place to gain hands-on experience and learn with from a global community

Top comments (0)