Goodspeed 🏃‍♂️💨

Let’s get back to our roots y’all.

Agile Principle #3
Agile Principle #3
Image by Author

Note: This is part of an ongoing series where we dive a bit deeper into the 4 values and 12 principles behind the Agile Manifesto. Click here to check out Agile Principle #2.

Agile Principle #3: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Before agile and Scrum became the way hyper-efficient software development teams operate, waterfall project management philosophies were rampant, most likely an artifact of industrial and manufacturing industries that fueled the economy before the digital revolution. On these projects, large phases of Analysis > Requirements Specification > Design > Development > Testing & Integration > Deployment were commonplace. Engineers were often handed 100+ page specification documents that took months of research and iteration to complete, even longer to code, and several more months to test and deploy. …


Let’s get back to our roots y’all.

Agile Principle #2
Agile Principle #2

Note: This is part of an ongoing series where we dive a bit deeper into the 4 values and 12 principles behind the Agile Manifesto. Click here to check out Agile Principle #1.

Agile Principle #2: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Core to the agile product development mindset shift is recognition that the world we live in is fluid. What the user wanted yesterday may not be what they want today when you finally release that shiny new product that you’ve been working on for months. Instead of assuming that we know what they want, how they’ll respond to product changes, etc. …


You ask ’em, I (try to) answer ‘em.

How can new teams quickly align to perform accurate user story estimation?
How can new teams quickly align to perform accurate user story estimation?
Image by Author

TL;DR When performing user story estimation with new teams, the goal should be to first align on what estimation scale will be used — most commonly the standard fibonacci sequence of [1,2,3,5,8] — then determine what each value represents to the team. To do this, identify historical user stories team members have completed in the past that closely align with the anticipated work the team will do in the future. Alternatively, use a few of the stories that have been refined for the next sprint or so. …


Let’s get back to our roots y’all.

Agile Principle #1
Agile Principle #1
Image by Author

Over the last couple of months I have been thinking a lot about the way agile and Scrum training can be improved. One fundamental difference between traditional certification courses and the approach I typically strive for lies in the emphasis I place on the 4 agile values and 12 agile principles as the foundational building blocks for the way teams should define and refine their agile working agreements. While how teams work together can change over time, the core agile values and principles remain a steadfast guide they can use to ensure team agility is never compromised. Most traditional agile and Scrum certification courses breeze through this critical portion, jumping straight to the Scrum process instead of strongly emphasizing the core agile philosophies. …


You ask ’em, I (try to) answer ‘em.

Image for post
Image for post

Q: Is it ever OK to re-point user stories?

Inevitably, teams encounter a user story that takes significantly shorter or longer than anticipated to complete and they want to change its’ story point value to reflect reality after the work has already been done. Typically, their motivation for doing so is to obtain a more accurate representation of the amount of work done in the sprint, often because velocity (the number of story points delivered in a sprint) is used by leadership as the measuring stick by which teams are evaluated — either by comparing velocity across teams or micromanaging changes in a team’s velocity sprint-over-sprint (fear the dreaded dip!). …


A core Scrum concept that’s often misinterpreted.

What is a story point?
What is a story point?
Image by Author

Story points are a fundamental concept most commonly utilized (for a variety of purposes) within the Scrum framework and are frequently misunderstood. For as critical and widely used as they are, many teams misinterpret what story points represent and how they should be used. So…

Q: What is a story point?

Story points are a fictitious unit of measure used to estimate the size of work increments in a team’s product backlog. They are used to quickly gauge the effort required to complete a user story relative to another user story the team has worked on in the past that is reasonably similar to the one in question. …


You ask ’em and I (try to) answer ‘em!

Teams should first strive for predictability, then focus on velocity improvement and optimization for better agile planning.
Teams should first strive for predictability, then focus on velocity improvement and optimization for better agile planning.
Image by Author

I’ve been walking a lot lately. The combination of COVID-related lockdowns and a general sense of I’ve-gained-too-much-weight-and-should-really-do-something-about-it has forced me off my couch and into the streets of Chicago on a daily basis, to the tune of nearly 7 miles a day. This gives me a lot of time to think. On one such excursion I pondered what my next agile-related story should be about — I want something that is both easy to consume and immediately actionable for development teams. And so it was that the Agile Q&A series was born.

The goal of this (hopefully ongoing and at least semi-frequent) series is to spark a conversation on pertinent agile-related topics and help spread general knowledge and best practices to agile teams around the world. I’d like these to be bite-sized pieces of information you can use to improve the way your team works together today.


5 easy steps to better stories.

Image for post
Image for post

TL;DR Well-written user stories are the backbone of an efficient agile software development process. When done poorly, the wrong thing gets built and teams waste enormous amounts of time on costly rework. When done well, teams are able to confidently forge ahead knowing they’re building the right thing. Investing the time to write kick-ass user stories also provides transparency to those outside of the scrum team through clearly articulated value of the work they do and what (specifically) is being built.

Poorly written user stories are pervasive in agile software development. Product owners know that acceptance criteria are important, but often write stories containing just a sentence or two of detail (if you’re lucky). Teams need more than this to properly prioritize them against other work in their product backlog, clearly understand the value of what they’re working on, feel confident that they’re building the right thing, and know when to call the story done. As the primary method of communicating what new functionality users desire, poor user stories often result in the wrong thing being built, ultimately leading to wasted time, effort, and money reworking issues. …


When Bigger Isn’t Better

The Art of Splitting User Stories
The Art of Splitting User Stories
Image by Author

TL;DR Small user stories reduce the risk of not achieving sprint goals and enable faster, more frequent, and consistent iterative development. Splitting user stories to the smallest reasonable size enables faster flow through the software development lifecycle by becoming easier to understand, estimate, develop, test, and deploy. Split vertically, not horizontally, to deliver thin slices of value.

Where exactly does the mentality “the bigger, the better” come from? It’s a common phrase that has been played out in American culture time and time again throughout history:

  • Fast food portion sizes have grown out of control over the last 30 years as burger chains across the country seemingly race the most artery-clogging chunk of meat award. …


The subtle art of getting close enough.

Estimation Jar
Estimation Jar
Quick — guess how many! (answer is below)

TL;DR Accurate user story estimation is hard — done well, teams can become consistent and predictable, resulting in more successful sprints and better long-term planning capabilities. Use techniques such as planning poker, reference user stories, and hyper-splitting to improve the accuracy of your team’s effort estimation — or don’t estimate at all (#noestimates, within reasonable bounds).

Imagine for a moment that someone asked you to estimate the number of skittles contained in the jar pictured above. How would you answer? To provide an accurate estimate, you’d probably want to know details like:

  • How big is the jar (diameter and height)?
  • How big is each skittle? …

About

Goodspeed 🏃‍♂️💨

Technical Program Manager @ Medium | Agile Nerd

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store