[woutr_be]

The amount of hours our team has wasted on estimating, re-estimating, splitting up stories, simply to make our burn down chart look great is amazing. We would often be forced to split up stories the day before a sprint review, just so that the chart would look like things have progressed, while in reality nothing was completed.

Our sprint planning sessions were a FULL DAY, yes, an entire 8 hours of planning. Because our scrum master wanted a detailed plan of what every engineer would be working on, on every day of the week.

I still remember a certain even where we were forced to adjust our story points, so that we could make a detail a month in the future. Yes, our “agile” team, had a hard deadline that we had to try and make work. This was the business decided that we’ll launch in a month, so now we’ll use our agile methodology to somehow make it magically work. During a full day session to plan for this, I suggested we should drop our scrum board and instead revert to kanban. The scrum master threw me a dirty look and told the business about this, pretty sure that’s why I was moved to another team.

[xtracto]

I have suffered through those sprint sessions of hell.

What has worked for me is the following:

- let the most sr tech person ("the architect ") refine the stories maybe with the PM. Then, the same person will point the stories. - The sprint planning is only for presenting the stories to devs and giving some minor adjustments to the points if necessary - The architect may deep dive with a dev for a certain task while pointing it. - That way we have a standard complexity measure. We know different devs will perform different amount of points per sprint . We dont lose time in pointless neverending discussions - it also works well in Mexico where people are not so vocal so the standard poker planning doesn't go well

[woutr_be]

Sadly because of the way our organisation works, the scrum master pretty much takes ownership of the whole process, he also sells agile to the business side. So if you go against what he says, the business will know that you’re a trouble maker, even if you had the best intentions.

Trust me, our team has tried, sadly the whole business wants to move to agile, and it’s shoved down your throat, wether you like it or not, or even regardless if it’s working for the team.

Eventually I gave up, the amount of energy wasted on these discussions is just not worth it. After a while you learn to say the right things, while also making sure you keep your technical freedom. Sometimes that meant not bringing up certain technical tasks, and overestimating others so that you have time for those other technical tasks.