this post was submitted on 22 Aug 2023
647 points (98.2% liked)

Programmer Humor

19586 readers
1030 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
647
submitted 1 year ago* (last edited 1 year ago) by rony4102 to c/programmer_humor
 

Damn! Team Just do it!!!

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 11 points 1 year ago (3 children)

My team has being trying an approach where instead of story pointing, we break everything down into the smallest incremental tasks we reasonably can and use number of tasks overall as the metric instead of story points.

In theory it's meant to be just as accurate on larger projects because the larger than normal and smaller than normal tasks all average out, and it save the whole headache of sitting around and arbitrarily setting points on everything based mostly on gut feeling.

[–] [email protected] 5 points 1 year ago

I remember reading a study done across some large organizations that showed this approach was more accurate than other estimation techniques. Makes sense to me.

[–] [email protected] 3 points 1 year ago

Huh. That's such a simple and obvious approach, I'm kinda mad I've never thought of it lmao. It seems like you're essentially breaking everything down to a 1 (or as close as you can get it), which is probably a more accurate measurement anyways. Neat.

[–] [email protected] 1 points 1 year ago

When I teach story points (not in an official Agile Scrum capacity, just as part of a larger course) I emphasize that the points are for conversation and consensus more than actual estimates.

Saying this story is bigger than that one, and why, and seeing people in something like planning poker give drastically differing estimates is a great way to signal that people don't really get the story or some major area wasn't considered. It's a great discussion tool. Then it also gives a really rough ballpark to help the PO reprioritize the next two sprints before planning, but I don't think they should ever be taken too seriously (or else you probably wasted a ton of time trying to be accurate on something you're not going to be accurate on).

Students usually start by using task-hours as their metric, and naturally get pretty granular with tasks. This is for smaller projects - in larger ones, amortizing to just number of tasks is effectively the same as long as it's not chewing away way more time in planning.