My teams current process is:

1) Asked by product to create “T-Shirt size” estimates, also known as a WAG (wild ass guess). The process is the mental equivalent of throwing darts while blindfolded, after being spun around in a circle and pointed in the wrong direction.

2) Product make firm commitments to upper management based off these. Ensuring them that all these features will make it out in Q2.

3) 4 days before Q2 starts, product ask engineering to figure out the real estimates based off no concrete information what so ever.

4) 4 Weeks into Q2, product provide the missing information.

5) Engineering inform product that the estimates are out by a factor of 1.5 - 3 times the original estimates.

6) Product sends angry email to upper management that through not fault of product, engineering are unable to meet the deadlines.

7) Everyone shout and complain until 1 week before Q3, then see point 1.

Following this process, you and your team can be just as delightful as me.

That’s the practiseSafeHex guarantee!

Sales employee Bob wants a clickable blue button.

Bob tells product owner Karen about his unstoppable desire for clickable blue buttons.

Karen assigns points for potential and impact (how much does a blue button improve Bob's life, how many people like Bob desire blue buttons)

Karen asks the button team how hard it is to build a button. The button team compares the request to a reference button they've built before, and gives an ease score, with higher score being easier (inverse of scrum points).

These three scores are combined to give a priority score. The global buttonbacklog is sorted by priority.

Once every two weeks (a "sprint") the button team convenes, uses the ease scores to assign scrum points. Difficult tasks are broken up into smaller tasks, because there is a scrum point upper limit. They use the average of the last 5 sprints to calculate each developer's "velocity".

The sprint is filled with tasks, from the top of the global button backlog, up to the team's capacity as determined by velocity. Approximate due dates are assigned, Bob is a happy Bob.

What if boss Peter runs into the office screaming "OUR IMPORTANT CLIENT WANTS A FUCKING PINK BUTTON WHICH MAKES HEARTS APPEAR"?

Devs tell boss to shut the fuck up and talk to Karen. Karen has a carefully curated list of button building tasks sorted by priority, can sedate boss with valium so he calms the fuck down until he can make a case for the impact and potential of his pink button.

Karen might agree that Peter's pink button gets a higher priority than Bob's blue button.

But devs are nocturnal creatures, easily disturbed when approached by humans, their natural rhythms thrown out of balance.

So the sprint is "locked", and Peter's pink button appears at the top of the global backlog, from where it flows into the next sprint.

On rare occasions a sprint is broken open, for example when Karen realizes that all of the end users will commit suicide if they don't have a pink heart-spawning button.

In such an event, Peter must make Bob happy (because Bob is crying that his blue button is delayed). And Peter must make the button team of devs happy.

This usually leads to a ritual involving chocolate or even hardware gift certificates to restore balance to the dev ecosystem.

Documentation is like sex... When it's good, it's very good. When it's bad, it's better than nothing.

Even if you unplug the router when Verizon tech support says they are going to run a test on it, they will say everything looks good and is running perfectly anyways.

Also, a tip. They will also try to sell you their newest router. Say you have that one already in every room and the speed is even lower than it was before, and then demand a refund because they sold you defective product. 9 times out of 10 they will unthrottle you instantly.

Can we all please try to keep emotion out of coding? It never ever helps to get upset at a code review.

Please please please accept constructive criticism, and dish it back to me! You can hate my code just don't hate me. :/

@Endurance are you my ex by any chance?

So as new user I used devrant straight for 6 hours and this happened.
Am I the only one who thinks this helpful tip should be given at 3rd upvote and not 80th?

An area sales rep once rang me to tell me his iPhone screen was cracked and was going blurry around some sections.

I told him to fetch me to look, and I will see what I can do.

5 minutes later I get a SCREENSHOT from his phone asking if I can see the crack and blurry edges.

HOW FUCKING DUMB ARE THESE PEOPLE!!!

I mean, come on. He seriously said when I called him: "But I can see the crack and blurry bits on the screenshot on my phone"

Rant that involved my manger hit a decent amount of ++.
Just seen him downloading devRant.

When the PM grabs my keyboard to show me how he thinks I should do the task...

don't disturb the coders who wear head phones. It will take 2 more hours to make them back to track