Developers and story points

Hey there! How was your day?

Another interesting conversation between the Team, at Infraspeak, today. We discussed why our story points’ estimates were constantly off. We program each Sprint to fulfill around 130 story points (team wise for a cycle of 3 weeks for a total of 8 enginners split between backend, frontend, mobile and integrations). This should not be too much, but we’re always falling (very) short against our own estimates.

While analyzing our Burndown Chart, Gonçalo noticed that we barely pulled the work line down, even though we have a lot of bugs, features, and an awesome Epic coming out this Sprint (the report me, Ricardo and João have been working). Looks like the Team had an overly optimistic sprint planning. You know how programmers are when it comes to planning and estimating: it’s all very quick, simple changes, but we keep missing the details, where we invest most of the time. Another problem is the fact that we haven’t mentalized, yet, that the issue is not really closed after opening the pull request and yet, maybe unconsciously, we think the work is done, and that now is time for the reviewers and QA people to deal with the rest. And that’s simply not true…

So, we decided to change this, for good. Starting at next sprint, we’ve decided to check, at every daily stand-up, everyone’s tasks, especially those that are, or passed, the Code Review stage, to force, sort of speak, each one of us to be more sensible and try to close as many tasks as possible during the sprint and not on the last day, which has been the norm so far.

I even proposed that we began to be a little more pessimistic in our poker planning (that planning phase were we attribute points to each task to be done) but the rest of the Team though that was not necessary. I still think it’s something we should do because we can always have a bug to fix or other unplanned situation and a little extra time to do it helps so to not disturb the current plan.

Let’s see what’s going to happen.