In the world of software we generally work in a few ways. The most common of which is 2 week sprints, but similarities between companies usually stop there. Some companies I’ve worked at had great burndown charts of fibonacci points per card to actual completion. Others had a more fly by the seat of your pants mentality and just got done what you could get done. Still others would measure velocity but never apply it to the sprints always filling it with more work than possible. The last one most often happened at companies where there was a disconnect between product management and engineering about timelines. When timelines are handed down from above with no engineering input, people get salty, timelines slip, and generally everyone just has a bad time.

I’d like to argue for a few things I would like to see in an ideal engineering environment and what a healthy relationship between product management and engineering looks like.

In a perfect world engineering teams would track points that are completely unrelated to any time scale and focus purely on complexity during estimation. Points that measure complexity can then be used to calculate team velocity so as to gauge the number of points a team can take on any given week and expect to complete them. It might seem strange because then points become used in measuring time but it’s by virtue of accurately estimating complexity that we can set expectations for the amount of work that can be accomplished in a given sprint.

Focusing on team morale and the ability to actually complete everything in a given sprint is important. Filling it to the brim and assuming your team will be unable to complete it prevents them from feeling like they’ve completed the sprint. This is called a “sprint”. People finish sprints where they run in real life and I feel we should apply the same to software sprints. We should be able to look forward to completing sprints as a team before, if not well before 5pm on the second Friday.

The Zeigarnik Effect