Odoworitse Afari

Posted on Mar 12

I Ran My First Real Agile Sprint and Shipped to Production Every Day for 5 Days

#devops #agile #aws #learninginpublic

Here's what happened when I stopped reading about DevOps and actually did it

I've read dozens of articles about Agile sprints. Watched YouTube tutorials on Jira. Taken notes on CI/CD workflows.

But until last week, I'd never actually run a sprint from start to finish.

My internship at CloudAdvisory changed that. The assignment: build and deploy a footer to a portfolio website. Simple feature, right? Add version number, deployment date, author name. Done.

Except the real assignment wasn't the footer. It was running a proper 5-day sprint, planning in Jira, committing daily, deploying to EC2, and documenting everything like a production team would.

Here's what I learned shipping code every single day.

Day 0: Planning (The Part Everyone Skips)

Most developers jump straight to coding. I used to do that too. Open VS Code, start typing, figure it out as I go.

That's not how real teams work.

I opened Jira and created a story: "Add footer with version and deploy date." Then I wrote acceptance criteria in Gherkin format—basically a checklist that defines "done":

Given I'm on the portfolio homepage
When I scroll to the footer
Then I should see:
  - Version number (v1.0)
  - Dynamic deploy date (today's date)
  - Author name (Odoworitse Afari)

Then I broke it into 5 daily subtasks:

Day 1: Build the footer, commit, deploy
Day 2: Make the date dynamic (no hardcoding)
Day 3: Polish the UI, test on mobile
Day 4: Update homepage tagline
Day 5: Demo and retrospective

📸

I set a sprint goal: "Ship a visible footer to EC2 with daily progress documented in Jira."

Then I clicked "Start Sprint."

The clock started ticking.

Day 1: First Deployment (It's Not Just `git push`)

I cloned the repo and created a feature branch:

git clone https://github.com/pravinmishraaws/Pravin-Mishra-Portfolio
cd Pravin-Mishra-Portfolio
git checkout -b feature/footer-v1

Added the footer to index.html:

<footer>
  <p>Pravin Mishra Portfolio v1.0 — Deployed on 6 Feb 2026 — By Odoworitse Afari</p>
</footer>

Committed:

git add .
git commit -m "feat(footer): add version, deploy date, and author"

Then came the reality check: deploying to EC2 isn't git push. It's manual work.

I had to:

Copy files to the server using SCP
SSH into the EC2 instance
Move files to Nginx's web root
Reload Nginx
Verify the site is live

scp -i my-key.pem -r . ubuntu@44.193.203.233:/tmp/portfolio
ssh -i my-key.pem ubuntu@44.193.203.233
sudo cp -r /tmp/portfolio/* /var/www/html/
sudo nginx -t && sudo systemctl reload nginx

📸

When I opened the site and saw my footer live on a public IP address, it hit different. This wasn't localhost. Real people could see this.

I went back to Jira and moved Day 1 to "Done." Added a scrum comment: "Shipped footer v1 to production. Live at http://44.193.203.233"

📸

What I learned: Shipping to production on Day 1 changes everything. It's not theory anymore. You have to verify it works, test it in a browser, make sure nothing broke. That's the difference between coding and DevOps.

Day 2: Making It Actually Dynamic

The footer from Day 1 had a problem: the date was hardcoded. "Deployed on 1 Feb 2026."

That's fine if you never deploy again. But in real DevOps, you deploy multiple times a day. You can't manually update the date every time. That defeats the whole point of automation.

I replaced the static date with JavaScript that generates today's date automatically:

<footer>
  <p>
    Pravin Mishra Portfolio v1.0 — 
    Deployed on <span id="deploy-date"></span> — 
    By Odoworitse Afari
  </p>
</footer>

<script>
  const today = new Date();
  const options = { day: 'numeric', month: 'short', year: 'numeric' };
  const formattedDate = today.toLocaleDateString('en-GB', options);
  document.getElementById('deploy-date').textContent = formattedDate;
</script>

Now every page load shows the current date. No manual updates.

📸

I also updated the README to document how it works. Future developers (or future me) shouldn't have to reverse-engineer this.

Committed, deployed, verified.

What I learned: Automation isn't just CI/CD pipelines. Sometimes it's replacing one hardcoded value with three lines of JavaScript. Every manual step you eliminate is one less thing that can break.

Day 3: Polish (Because "It Works" Isn't Enough)

The footer worked, but it looked terrible. Text was cramped, contrast was weak, and I hadn't tested it on mobile yet.

I updated the CSS:

footer {
  padding: 2rem 1rem;
  background-color: #1a1a1a;
  color: #f0f0f0;
  text-align: center;
  font-size: 0.9rem;
  border-top: 1px solid #333;
}

Then I opened Chrome DevTools and tested on:

Desktop (1920x1080)
Tablet (768px)
Mobile (375px)

The footer was responsive and readable on all screen sizes.

📸
![Portfolio website footer displaying version 1.0, deploy date, and author name on live EC2 server]](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t09vqg2z5cema109i044.jpg)

📸

Committed, deployed, verified.

What I learned: "It works on my laptop" is not production-ready. Real software needs to work for everyone, on every device. Polish matters.

Day 4: Bonus Feature (Small Wins Add Up)

While I was at it, I updated the homepage tagline. Instead of static text, I added a Discord invite link to the DMI community:

<p>
  <a href="https://discord.gg/dmi-cohort3" 
     target="_blank" 
     rel="noopener noreferrer">
    Join the DMI Community on Discord
  </a>
</p>

📸

Small change, but now the homepage has a call-to-action instead of passive text.

Committed, deployed, verified.

What I learned: Every sprint should leave the product better than it was. Small improvements compound.

Day 5: Demo, Retro, Burndown (Closing the Loop)

I recorded a Loom video walking through everything I shipped:

Footer with dynamic date
Mobile responsiveness
Homepage CTA
Live deployment verification

Then I ran a retrospective:

What went well:

Clear acceptance criteria made implementation straightforward
Daily commits kept progress visible
Incremental deployments caught issues early

What could improve:

Should have tested mobile view on Day 1, not Day 3
Manual deployments are slow—need automation

Finally, I opened the Jira Burndown Chart. It showed steady progress from Day 1 to Day 5. No scope creep, no blocked work, just consistent daily execution.

📸

Sprint goal achieved.

What Running a Real Sprint Taught Me

1. Sprint Goals Keep You Focused

"Ship visible footer improvements" isn't just admin overhead. It's a filter. Every time I thought about adding extra features, I asked: "Does this help achieve the sprint goal?" If not, it goes in the backlog.

2. Daily Commits Build Discipline

Shipping something every single day, even if it's small, creates momentum. By Day 5, I'd deployed 5 times. That's 5 reps of the deployment process, 5 times verifying the site was live, 5 times documenting work in Jira.

3. Agile Is About Shipping, Not Tickets

Moving a Jira ticket to "Done" feels good, but it's meaningless if the code isn't live. Real Agile is about shipping working software. Every day I asked: "Is this live? Can users see it?" That's the standard.

4. Documentation Is Part of the Work

Updating the README, writing acceptance criteria, logging daily scrum notes this isn't busywork. It's how teams stay aligned. Without documentation, the next person wastes time figuring out what you built.

5. Retrospectives Drive Growth

On Day 5, I didn't just celebrate finishing. I asked: "What slowed me down? What would I do differently?" That's how you improve.

What's Next

This sprint taught me that Agile isn't a process you follow. It's a mindset. Ship small, ship often, improve continuously.

My next steps:

Automate deployments write a script to eliminate manual SCP/SSH
Add CI/CD set up GitHub Actions to deploy on every push
Implement rollback what if a deployment breaks production?

If you're learning DevOps, try this: pick a small project, break it into daily tasks, and ship something every day for a week. You'll learn more in 5 days of shipping than in 5 weeks of tutorials.

Tools I Used

Jira (Sprint planning, backlog, burndown)
Git + GitHub (Version control)
AWS EC2 (Production server)
Nginx (Web server)
VS Code (Code editor)
Chrome DevTools (Testing)
Loom (Sprint demo)

Connect

I'm Odoworitse Afari, a junior DevOps engineer building in public. If you're on a similar path, let's connect:

LinkedIn: linkedin.com/in/odoworitse-afari
GitHub: github.com/0dow0ri7s3

DEV Community

I Ran My First Real Agile Sprint and Shipped to Production Every Day for 5 Days

Here's what happened when I stopped reading about DevOps and actually did it

Day 0: Planning (The Part Everyone Skips)

Day 1: First Deployment (It's Not Just `git push`)

Day 2: Making It Actually Dynamic

Day 3: Polish (Because "It Works" Isn't Enough)

Day 4: Bonus Feature (Small Wins Add Up)

Day 5: Demo, Retro, Burndown (Closing the Loop)

What Running a Real Sprint Taught Me

1. Sprint Goals Keep You Focused

2. Daily Commits Build Discipline

3. Agile Is About Shipping, Not Tickets

4. Documentation Is Part of the Work

5. Retrospectives Drive Growth

What's Next

Tools I Used

Connect

Top comments (0)

Here's what happened when I stopped reading about DevOps and actually did it

Day 0: Planning (The Part Everyone Skips)

Day 1: First Deployment (It's Not Just git push)

Day 2: Making It Actually Dynamic

Day 3: Polish (Because "It Works" Isn't Enough)

Day 4: Bonus Feature (Small Wins Add Up)

Day 5: Demo, Retro, Burndown (Closing the Loop)

What Running a Real Sprint Taught Me

1. Sprint Goals Keep You Focused

2. Daily Commits Build Discipline

3. Agile Is About Shipping, Not Tickets

4. Documentation Is Part of the Work

5. Retrospectives Drive Growth

What's Next

Tools I Used

Connect

Day 1: First Deployment (It's Not Just `git push`)