The concept of story splitting is simple enough. Your engineering manager wants you to go “faster”; really what he’s asking for is more story points per sprint. The way to achieve this isn’t actually to “code faster”, since we’re limited in how fast we code by a multitude of things. The real answer is to give your manager more insight into what you’re doing at any given point in time. This is achieved by taking your current work and splitting it into more bite-sized chunks that are easily digestible. Yum. But how do you accomplish this?
After trying to split stories for about a year and a half seriously now, and very much failing. I had a kind of “AHA!” or Eureka! moment. What if I actually just treated every story given to me as an “epic”? Really, the tasks/stories given to me are just functionality we need added to the website, in one way or another. They typically last 1->6 months (in the worst cases). So in the extreme cases they actually are epics lasting 6 months, and in the short-case they are still not what’s thought of as “thin vertical slices”.
So after my big aha, I put the task I’m given at the “design” phase, and then start splitting off stories on what I’m pull requesting into the codebase. The other big “aha!” moment immediately after this - just because I PR something into the codebase doesn’t mean the actual behaviour of the codebase has to change. Really I’ve just made a stepwise change that improves something, adds a feature, or the ability to add a feature. My current task is to get rid of some large methods on an even larger class. I start making each move of a large method a PR, and thus it is also a story on my board. Whether its separating domain logic from database logic, or figuring out where that gnarly utility method actually belongs and moving it, they are all stories.
The jury is still out on my story-splitting experiment. I plan on creating new stories for the next week, until either the sprint retrospective on Wednesday, or my Engineering Manager 1-on-1 on Thursday. I want to see how it pans out - is this actually a useful exercise? Or a total waste of time and purely a thought experiment? I don’t really know, but hopefully I remember to update this blog when I find out.
For those that would prefer a TLDR; in code form
function GarbageInGarbageOut() {
// definitions
const developmentEstimation = "hard";
const storypointing = "estimation";
// logic
if (storypointing == estimation &&
developmentEstimation !== "easy" &&
developmentEstimation === "hard") {
return true;
} else {
return false;
}
}
I actually have to re-read this article, in light of my above logic. Writing out the argument in code allowed me to see flaws in the arguments. This article is currently a WIP until I remove this note and flush out my thoughts more.
The underlying problem for developers posed by “lets do story-pointing”, or trying to record a length/complexity of time for a task, is that their tasks are not easy to estimate. In fact, they fit what ChatGPT defines as a poor tasks to estimate.
What makes a task easy to estimate? It’s tasks that fit on the following dimensions
What makes a task hard to estimate? ChatGPT rates it difficult if it falls into the following dimensions
In short form, we can answer “yes” to all the above. Development tasks readily fit into the buckets we don’t want for estimating something.
There is an obvious counter-point here. If you know exactly how long a task is going to take, why estimate it at all? You could just give the person the task, and come back however many days needed later to pick-up the item.
What is the purpose of estimating? Estimating time for tasks fits into the following categories. These initial four I saw the value immediately.
These four items I think takes a bit more convincing that it’s a benefit of estimating developer tasks.
The value proposition of project management lies in its ability to systematically plan, execute, and complete projects efficiently and effectively. Here are the key components of this value proposition:
The value proposition of project management is its ability to deliver projects successfully by enhancing planning, resource management, risk mitigation, communication, quality, time management, cost control, continuous improvement, and stakeholder satisfaction. This comprehensive approach ensures that projects are completed efficiently, effectively, and to the satisfaction of all parties involved.
The say do ratio is used to prevent spillover from stories/tasks in a single sprint. Its a ratio that is meant to drive splitting stories or working in smaller incremental values.
User Story: A single chunk of work that is scoped down to the minimum possible increment that STILL has meaning to the user. Example: If you are clicking a button and that triggers 10 microservices in the backend, the smallest unit of work is the button click and whatever behaviour changes in reference to the user afterwards (Perhaps an email gets sent).
Technical Task: A single chunk of work divided from a user story that still delivers an incremental piece of value that still has meaning to a developer. Example: If you are clicking a button and that triggers 10 microservices that are all in separate repositories, the incremental value unit will be at least as big as 10 pull requests into each microservice (assuming these are separated).
Say/Do Ratio: A ratio made in an effort to size down or further split a unit of work - this could either be a User Story or a Technical Task. Story points are supposed to be used to get the units. These should be “committed” status stories only in the numerator, and I believe all stories are the denominator.
Examples - User Stories: Sprint Results 01/01/2024 (2 week increment):
Examples - Technical Tasks:
Sprint Results 01/01/2024 (2 week increment):