It is usually after a disaster (small or big) that people start proclaiming: The application should NOT crash! The application should NOT block waiting for that downstream service! The application should NOT allow unauthorised access! And similar statements describing what the application should NOT do instead of what it should. After such a proclamation and since the statement, or at least the intention behind the statement is reasonable, people are left trying to figure out how to do that.

In my previous posts Sprint velocity, what is it good for? and Better sprint planning with Bayes, I talked about using statistics for more reliable forecasting and for quantifying uncertainty. In this post, I want to show you the code to automate the process, so that us humans can focus on making decisions based on the data. I am going to use Python for this example, because it has great libraries for data science and statistics.

Imagine you are working in a software development team doing Scrum with 2-week sprints. If you are part of a larger organisation, it is likely there are delivery goals that go beyond the next sprint, let’s call them milestones. Inevitably, someone from above is going to ask you: “Are you on track? Are you going to make the next milestone?” This is what happened to me recently, and I struggled to come up with an answer.

Software development teams doing scrum try in one way, or the other to measure their velocity. Velocity is usually measured as the number of completed stories or as the number of completed story points in a sprint. The first one is pretty straight forward, the second one is a bit more elusive, so I am going to explain it further in the next section. Especially, since I’ve seen teams spend quite some effort trying to get the story points right!