Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Story points, I've never seen work anywhere, we estimate in 0.5 day increments.
We seperate the estimates into Dev, QA, UAT, and Deployment.
What ever the total is, thats the total.
If any 1 sub estimate is greater then 2 weeks, the ticket is broken down into functional deliverables.
It generally works, and... sometimes... it's a shit show. -
Hm. Sounds like scrummy dummy.
(Not my opinion, just playback)
Fibonacci is used to ease up the estimate process, since you have less numbers to choose from.
Dev, QA and Deploy can be part of the DoD, however the whole team has to form a consensus on the story points. (Planning poker)
(My Opinion)
Breaking up a part into less than 5 story points is wasting resources.
The overhead is especially in Scrum pretty extreme...
What's worse is that the velocity <should> suffer, since your estimate can only be off imho.
An good example is usually the necessity to do the same changes in 3 different projects.
Since you create 3 tasks to fulfill the story point rule, you'll have in the worst case 3 different people doing the same task plus the now necessary synchronization.
I'm not a fan of scrum... It's micro management hell with group punishments. -
I experienced this exact scenario at my last company, it was also my first company so I didnt know any different.
Now I do, its stupid. I still work on a team that uses fibonacci and honestly I still think thats dumb and arbitrary but it works out ok for us because we only use the estimates to gauge how much to bring into a sprint. -
My team is pretty similar, with the fibonacci point values and splitting 8+ point stories up, but we also are allowed to split dev/QA/prod deployment up into separate stories (and we usually do that unless it's a very small task). We've found it actually works pretty well, although I'm not sure if it's actually a good system or just that our previous system was so bad that the new one only seems great in comparison.
At my company we have a rule that ticket estimates can only be pointed using numbers from the fibonacci series. So 4 point tickets are not allowed!
We’re also discouraged from giving an estimate larger than 5, and told that tickets need to be broken down into smaller tickets if we think it’s more than a 5.
Also, ticket estimates must include the full amount of time for dev, QA, AND deploy. Given how hard it is to work with our tech stack, few tasks actually fit.
All of this may sound fine in principle, but in practice it’s extremely frustrating. I’ve protested a few times but I’ve been told I’m outvoted and nobody wants to reconsider the decision that was made sometime in the distant past. I was also told that “most other companies do it this way”, so therefore we have to as well.
This is the first company I’ve ever worked at which had this stupid rule. Is it this way at your company? Is this a NorCal tech company thing? I’ve worked at several companies outside of the SV bubble, and never encountered this.
rant