I’m working on a project that will allow me to put some Agile and DevOps skills to use by writing a small app that I’ve had in mind for a while now. My wife and I decided a couple of years ago to visit all 50 states. We then decided to make it more fun by running a race in each of the 50 states. This app that I build will track our progress. I’m sure that apps like this already exist, but by writing it myself I’m able to get my hands dirty and see what works and what doesn’t in terms of DevOps tooling and techniques for smaller projects. I also gain insights into methods of hosting the app locally and in the cloud on a variety of platforms - vms, containers, serverless, etc. with different databases.

I’ve laid out some of the basics in two previous articles. The first was an overview. Part 2 discussed choosing a work tracking mechanism and code storage solution. This article will dig deeper into adding tasks such as Product Backlog Items to the board. I’ll also describe a little more my approach to Scrum as I’m both the customer and the developer. In Scrum terms, I’m both the Product Owner and the Scrum Team. Before I begin to add items to the board, it’s important to decide on the events and cadence of the project.

One Man SCRUM

I’ll admit that it’s a bit odd to apply a team based approach to development like Scrum to a 1 man project. But as I stated in part 2, this is more of a way for me to reinforce what I learned in my Certified Scrum Master course, than an exercise in pure practicality. There are multiple Scrum and Scrum Master certifications. I achieved mine via the Scrum Alliance.

Scrum practitioners use a few different events during the course of a project. I’ll adapt those events to suit my work style.

The Sprint - The Sprint is the amount of time given to get something “done.” This usually means you’ve made something useful. The Sprint Guide recommends making the Sprint 1 month or less. I’ve typically seen Sprints of 2 weeks. I can’t say that that’s an industry guideline, but for most enterprises, that seems an OK duration. My sprint timeline will be 1 week. I don’t have to collaborate with folks. I don’t need to ask permission of anyone, nor do I need to wait for other groups to provide resources. Since I’m the only bottleneck for my own issues, I’ll give myself 1 week deadlines.

“Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.“

Source - https://www.scrum.org/resources/scrum-framework-poster

Sprint Planning - Sprint Planning is a time boxed activity where the list of to-do items is created. The Scrum Guide says this should be about 8 hours for a 1 month long sprint. My Sprint is set for a week, so my Sprint Planning session will take no more than 2 hours (assuming it’s 2 hours per 1 week in a Sprint).

Daily Scrum - The Daily Scrum is a 15 minute morning session where the previous day’s activities are reviewed, the current activities for the day are decided upon, and any impediments are listed and considered. While this works well in a group setting, I can see it working equally well with a single contributor. Every day should start with centering on where you’ve been and where you wish to go. Timeboxing it at 15 minutes prevents too much reflection. This stays.

Sprint Review - In this meeting, the Scrum Team shows the product owner what is “done.” The product backlog can be cleaned up and there’s a discussion of what went well, timelines, budgets, and what to do next.

Sprint Retrospective - The Sprint Retrospective is a short meeting where the Scrum Team reviews what worked and where things can improve in terms of the framework. This review occurs before the next planning session.

Since I’m both the Scrum Team and the product owner, a Sprint Review will look very much like a Sprint Retrospective. Depending on how this goes, I might end up combining the two. The cool part about Agile is that it encourages learning and experimentation which is what are at the very heart of this project.

Work Item Types

The SCRUM Template in Azure Boards supports some Work Item Types (WITs) that don’t fully align with the Scrum Guide. The decision has to be made to either work with what’s there or modify the configuration. Richard Hundhausen (@rhundhausen on Twitter) has documented some of the differences he’s found as well as how to alter the template to align more closely with the Scrum Guide. Those articles are listed below.

MICROSOFT, PLEASE GIVE US A SCRUM PROCESS TEMPLATE - http://accentient.com/blog/microsoft-please-give-us-a-scrum-process-template/

CREATE A PROFESSIONAL SCRUM PROCESS - http://accentient.com/blog/creating-a-professional-scrum-process-in-vsts/

Azure Boards has several WITs for the backlog including Bug, Epic, Feature, Impediment, Product Backlog Item, Task and Test Case. None of those are found in the Scrum Glossary at Scrum.org (https://www.scrum.org/resources/scrum-glossary). A lot of these concepts are from SAFe and will be very comfortable if you live and work in that world. For example, Epics are are big deal and span multiple program increments and may even span multiple Agile Release Trains. There are formulas (like Weighted Shortest Job First) for computing which Epics should be completed to produce maximum return on effort. More about Epics can be found at the Scaled Agile Framework website (https://www.scaledagileframework.com/). It would make more sense for Microsoft to have a template specific for SAFe.

Instead of modifying the template, I’ve decided to avoid using WITs that don’t apply to the basic Scrum Framework. As such, everything will be entered as Product Backlog Items.

The first few backlog items will be dedicated to building and configuring the vms. I need infrastructure to host the code, and I want that infrastructure defined as code as explained in Part 1.

After about an hour or so, I’d completed Sprint Planning and entered more items into the Sprint Backlog. All items were assigned to me even though it’s a bit redundant. I used three prefixes to provide at-a-glance direction of the work items.

App Code - Tasks associated with the code writing and database related tasks
IaC - Infrastructure as Code tasks. These are Ansible code related in this phase.
Server Config - Tasks related to the base install of the vms. These are tasks outside of Ansible tasks

The work items can be assigned to Sprints after the items are entered. I’ve decided all the Server Config and Infrastructure as Code (IaC) tasks make sense to complete in the first week, so I moved them to Sprint 1. I also set dates on Sprint 1 to last 5 work days. If they are completed faster than that, I’ll pull in additional backlog item. No estimations will be provided since I’m not worried about forecasting for management (the joys of working on something for me!).

A screen that resembles a Scrum board or a Kanban board is visible once the work items are assigned to a Sprint. How you configure the board depends on your work style. I learned the columns as To-Do, In Progress, and Done. I also learned that an additional column, “Really Done,” could be added based on the politics of and organization. A fairly thorough examination of the differences between Kanban and Scrum Boards can be found here (https://miro.com/blog/scrum-kanban-boards-differences/). The default board columns will be renamed to suit my preference for column names. By default, the column names are Approved, Committed, and Done.

Default board with default column names - Approved, Committed, and Done

Board changes are simple. The names can be changed by selecting the column name and typing a new value. My Sprint 1 board will appear more complete as I work on and complete more tasks. The full backlog appears in the New column. I moved my intended tasks for Sprint 1 into the To-Do column. The first server build task was moved under In-Progress.

Next Steps

With the Sprint Planning completed, it’s time to do some hands on work and complete tasks.

Previous Articles in the Series

Part 1 - Long Term Project - Sample App + DevOps + Agile

Part 2 - Long Term Project - Part 2 - Azure Boards Configuration

References

Schwaber, K., & Sutherland, J. (2017, November). The Scrum Guide. Retrieved January 28, 2020, from https://www.scrum.org/resources/scrum-guide

Prokopets, M. (2019, September 14). The Top 10 Scrum Boards You Should Be Using. Retrieved January 29, 2020, from https://usefyi.com/scrum-board/

Kanban vs. Scrum boards: 11 major differences. (2019, December 10). Retrieved January 29, 2020, from https://miro.com/blog/scrum-kanban-boards-differences/

Miller, T. (2017, March 28). Optimizing Product Backlog Refinement. Retrieved January 29, 2020, from https://www.scrum.org/resources/blog/optimizing-product-backlog-refinement

KathrynEE. (2019, April 10). Scrum process template artifacts - Azure Boards. Retrieved January 29, 2020, from https://docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/scrum-process?view=azure-devops

Epic. (n.d.). Retrieved January 29, 2020, from https://www.scaledagileframework.com/epic/

KathrynEE, Jacobs, M., Danielson, S., & chcomley. (2019, February 13). Assign backlog items to a sprint - Azure Boards. Retrieved January 29, 2020, from https://docs.microsoft.com/en-us/azure/devops/boards/sprints/assign-work-sprint?view=azure-devops