161–170 of 300 posts
Story points are in fact time, and I'm tired of pretending they're not. You can sugar coat it all you want and say they represent complexity, but at the end of the day(or sprint), the higher the complexity, the more time it takes to complete.
Given the size of my scroll bar, I rate reading this article a 13. My PM has decided I shouldn't bother reading it, as the likely value isn't worth the effort, because whenever we take on a 13, it ends up dragging on for like 4 sprints, and preventing a lot of other higher value/lower effort stuff from getting done. Maybe at some point in the future, we'll break the article and have a few people on the team each read…
In my world, on my team - everything is a 3. and if its not a 3 lets figure out why. IE, lets have a fairly sized piece of work we scope for most tickets. If its bigger than that, lets discuss it, see if its worht breaking down (if its larger) and if not lets just agreee thats a larger piece than 3. that way we can just keep an eye on relative size of issues.
I am reading this slowly and there’s some good stuff in here, but it’s really long and I don’t have 1-2hrs to sit down and read it properly. I liked the suggestion of having a dedicated architecture team to break things down into work items. Comment your favourite parts/highlights?
I struggled with the length but couldn’t find a good way to shorten it more unfortunately. That’s the main reason I included a TLDR. Thanks for giving it your time though.
My personal experience with story points is that the number never really mattered, but the process of the team discussing how to rate the complexity of a task was very useful. In terms of having utility of estimating how long something will take, I personally have never been able to translate story points into a reliable indicator for that for many reasons (e.g team changing, domain changing, variability in operation…
When there was disagreement, it helped them dig deeper to understand why and usually reveal somebody's incorrect assumptions.
It helped make sure teams didn't overcommit to the amount of stories they stuffed into a sprint and avoid either burning out, or worse, normalizing not finishing the sprint causing negative impacts to morale/motivation. (For some reason my teams often thought they could do more than the points implied!)
Most importantly, when large projects were proposed or were in progress, we were able to give realistic estimates to the various stakeholders about when to expect the various milestones to arrive, which bought us engineers a ton of credibility, trust, and respect with the rest of the company.
And yes, management wanted to see the story points and measure the team against them. I told them to F-off. Nicely. Kinda.
It helped that I was either a CTO or a senior enough exec in those cases with 3-8 agile teams. I essentially was the middle management and could put a stop to any destructive practices like evaluating teams against their velocity.
There is nothing saying you can't refine work packages together in your team, while still using story points. That's actually how it's done almost everywhere. When items end up with a very high estimate there will be a push to refine it to something smaller. Something you should do but only as long as it still makes sense.
In fact the worst place i ever worked at was where we were given strict orders to break down every story until they all became 1 story point (still using story points...). Doesn't take a genius to figure out what happened next. All packages started having pointless micro-tasks with thousands of cross dependencies between them: "open the editor", "write a function" "write a unit test", "commit the code", "review the code". How am i supposed to write a unit test before the function signature has even been made? How am i supposed to iterate when finding bugs? More complex tasks still overran their estimates by factor 10, in fact even worse than before, some things just can't split, yet they still needed 1 point estimate.
Using the queue length and the impact on variability is still an interesting concept, i just don't think you should connect it with breaking down everything into single-sized items.
Earlier quoted context omitted.
Software does not exist in a vacuum. You are probably right in thinking that story points should not matter to you, as a developer; but they do matter to external stakeholders. Forecasting and management of expectations is necessary because software often has external real-world dependencies: available funding for a first release, marketing materials, hardware that can't be released without software, trade shows, dev…
There was a part of the article that discussed that you create tasks, not stories. You can group the tasks into stories or milestones or iterations or epics. In general, he’s saying you should always keep breaking down a task until it’s a 1, since 1s are easy to estimate. The key part that may be missed is the “mob programming” or “pair programming” aspect where all the engineers on a team sit together and work throu…
My issue with this has always been that once an issue is straightforward enough to estimate as a 1 point task, you could’ve implemented the task already during the estimation process. The unknown effort is almost never in the writing code part, but figuring out the complexities around business rules & externalities.
But this doesn’t fix the process, it just moves the variability of effort & time into a different part of the process.
My personal experience with story points is that the number never really mattered, but the process of the team discussing how to rate the complexity of a task was very useful. In terms of having utility of estimating how long something will take, I personally have never been able to translate story points into a reliable indicator for that for many reasons (e.g team changing, domain changing, variability in operation…
I used story points for years with my teams and they worked "as advertised", which is they helped the teams understand the effort, complexity and risk for each story involved. When there was disagreement, it helped them dig deeper to understand why and usually reveal somebody's incorrect assumptions. It helped make sure teams didn't overcommit to the amount of stories they stuffed into a sprint and avoid either burni…
Earlier quoted context omitted.
Ultimately, we are bound by time, not complexity. Why does it matter how complex a task is? The product managers and customers wont care how hard we as engineers have to think or reason about a problem; to them, the only thing that matters is time until delivery.
So they are bad product managers and customers. Time until delivery for good managers and customers is a range. Can you estimate getting 10kg of potatoes from grocery store that is 35m driving roundtrip away? Can you say it will be exactly 40mins because you can pick up and pay in 5 mins? I don't, I can say it will take between 40mins and 2h. There are always things like card terminal stops working or you get stuck i…
Sometimes it's not. In the gaming industry Christmas is a hard deadline.