Recently my wife asked me to build her a shed. More correctly, overflow storage for her clothes, we already have a shed for the normal shed storage stuff. She wanted a sort of walk-in closet but not connected to the house. Little did I suspect the teaching moment I would discover.
For two reasons I had to do most of the work on weekends. First, I have a full time day job. And we live in South Central Texas where summer evenings are still blazing hot.
So I broke the project up into smaller efforts which I felt I could complete in a weekend. Build the floor, build the walls, add the roof, install flooring, racks & shelving. At the end I could deliver additional storage at a far lower cost than a home addition. Win win.
It was the weekend of installing the floors and storage shelves that I realized I had a Scrum story to tell.
A Scrum Story
In this tale my wife is the on-site customer who will be acting as the Product Owner. The problem my customer had was too many clothes to fit into the existing closets in our house. No matter how hard she tried.
So we decided to build a product – a shed for clothes storage. The Product Vision was to have enough storage where she could easily find her clothing. With room to expand her collection of course.
By breaking down the Product Goal into smaller increments, roughly a week in size, we created a series of Sprint Goals. The series of Sprint Goals formed a Product Roadmap.
Because this was creation of a physical product, the construction required a particular order, the sequence of Sprint Goals was fixed. There was no way to deliver a roof before there were walls.
However, in a software product, the sequence should be more flexible. The Product Roadmap should aid in sequencing, promote tradeoff conversations, and is often reviewed. The roadmap should not be a fixed, calendar based commitment. Being flexible, and keeping options open, increases organizational Agility.
Sprint 1 Goal: 120 square foot shed platform/floor
As the foundation of our product, completing this Sprint Goal with a very high degree of quality was essential. This was pretty straightforward, leveling the ground, building the frame and attaching the plywood floor.
Everything went smooth this Sprint and the PO was very pleased with the results. The floor was solid, square and level. There were no changes to the upcoming Sprint 2 Goal or major changes to the ways of working as a result.
Aside – if you ever decide to build something outdoors, require a solid foundation and are tired of using heavy cement deck piers, check these out:
Sprint 2 Goal: Walls, Windows and Doors
During Sprint 2 we had the first deviation from the initial plan. The shed was to be lean-to style with the roof sloping away from the house. In the picture above, the roof would slope left to right.
After I built and stood up the wall furthest from the house, the PO decided that the roof should slope in a different direction. By pairing the team (me) with the PO during construction, real-time feedback and adaptation was possible.
So rather than the wall to the left (nearest our house) being taller than the wall furthest from our house, it would be the same height.
The work items (walls) themselves could change but the Sprint Goal remained the same – add walls, windows and doors. After some remeasuring and moving door locations, I added the remaining walls.
The Review was very successful and demonstrates how work items, perhaps user stories, selected during Sprint Planning can be adapted during the Sprint. As long as the Sprint Goal remains valid deviations from the initial Sprint Plan are perfectly fine. This is demonstrating Agile At Speed.
Sprint 3 Goal: Roof
As it relates to this story nothing of interest happened in Sprint 3. The metal roof that I added did not leak during the next heavy rains. Wohoo!
Sprint 4 Goal: Flooring and Shelves
Sprint 4 is where things get interesting. The team, meaning me, wandered off script a bit.
Friday evening, after making the Sprint Plan for the weekend, including installing flooring the next morning, I opened a bottle of red wine. As it turns out, it was a very good red wine. And I made homemade pizza. I enjoyed both far too much.
The next morning, as I attempted to renegotiate the Sprint Goal of installing flooring with the PO, she reminded me of the evening before. She said I was free to adapt the work items but drinking wine was not one of them. It was a choice I made to work outside the plan. Actions have consequences.
And while it was nearing mid 90 degrees before lunch, the PO was nearing 212. So I stuck to the plan, paying the price for activities not contributing to completing the goal. The LVP floor came out excellent.

Changing Sprint Goals
It turns out the developers are free to work on items that don’t contribute to the Sprint Goal. However, doing such work rather than contributing to the Sprint Goal is not a valid excuse to change the Sprint Goal.
The Sprint Goal is the one unifying achievement for the team during the Sprint. It is something that provides value to the customers. It helps the team identify valuable work items for the Sprint.
There are provisions in Scrum to change the Sprint Goal. Cancelling the current Sprint and re-planning is the correct approach.
There can be valid business reasons to do this. Going off script, even when the pizza and wine are very good, isn’t such a reason.
But a word of warning, cancelling a Sprint is a stressful activity to avoid if possible. It’s highly disruptive. In 15+ years of coaching teams using Scrum I’ve only ever needed it once. And that was to avoid $1M per month penalties if the team didn’t alter plans.
Until next time!
