# How to get sprint progress from complexity-based estimation?

We are a small IT team in a startup and are composed as such:

• 2 frontend engineers (1 senior, 1 junior)
• 2 backend engineers (1 senior, 1 junior)

We recently (3 months ago) started to use a Scrum methodology to manage our projects. It brought us stability and better communication (thanks mainly to the daily stand up meetings). So overall, it's a good change.

But, one thing remains. We try to estimate our stories by complexity, and assign a certain number of points for each sprint. Our team being small and the experiences in the different aspects of our projects, we have to assign specific stories to specific people in the team.

How can we know if we estimate by complexity, at any given moment, if we're ahead or behind schedule? Our sprints are two weeks long, we can't afford not knowing if we're late until the end of the sprint. Knowing that we missed our deadline at the deadline is pretty useless... And we can't rely on the estimation being diluted across the team, as we are this small.

Another thing I don't really get is we select the stories, let's say 120 points, for 2 weeks. It's a mean of ~30 / person so my engineer's brain is telling me that I should, give or take, do 3 points per day. If on the third day I'm at 9, I'm good. If I'm at 6, I'm behind. But there I'm back on a time based estimation...

I guess I don't get the thing about complexity estimation. I understand the power behind relative estimation, as this answer explains it, but I don't see how I can keep track of the well being of the project while in a sprint.

Nota bene: we do have a burndown chart, which is not that useful for my conceptual problem as it draws a chart of complexity over time. Therefore, can I deduce that the points are time-based in the end ?

• The power of the relative estimation is to do some form of longer term prediction; being able to guess what you may be able to deliver a couple of sprints ahead, and having a sense of whether somehting will actually fit in a sprint. Nothing prevents you from coming up with a more detailed plan in the Spint planning. And nothing is forcing you to keep using Story Points or complexity at thi spoint. You're now looking only 2 weeks ahead on relatively well defined chuncks of work. You are likely able to convert that to something more concrete than complexity. And that;s just fine. Dec 1, 2016 at 9:39

I'm assuming you've already created a Story based burn-down chart (If not, do that now). The problem is all the value is suddenly appearing at the end? This isn't a problem with the metrics, you might have too much work in progress?

Too much work in progress is bad. It makes progress hard to measure. But it also has other shortcoming, like increasing the risk that a bad sprint delivers nothing (eg two stories 60% done) rather than something (eg one 100% done, one 20& done).

There are a number of things you can do to improve your work in progress problem, here are a couple: 1) Make your stories small 2) Cooperate more. Put your 4 people on 1 or 2 stories at a time, rather than 4. Focus as a team on delivering something as soon as possible.

N.B. Task based burn-down charts. Might be useful sometimes. Use with caution though, they can be deceptive. Tasks aren't (and shouldn't be) estimated, may been uneven in size and more can appear as more work is discovered or as larger tasks are broken down. Also tasks don't actually represent delivered value.

• Hey Nathan. We do have a burndown chart, which gives us progress of complexity over time, which is strange IMO. That's why I was considering the points as time-based
– Stan
Dec 1, 2016 at 16:27
• @Stan I don't think I fully understand what you mean. Afaik, points are a measure of relative complexity. They have no fixed relationship to time. This is deliberate, with "velocity" being the link. I think it's safe to assume that if you've fully completed say 6 points out of 12, you will be at least half way through. My central assumption here is that you aren't burning down on stories actually complete until the end of the sprint, is this correct? Dec 1, 2016 at 16:33
• We do complete stories alongside the sprint. But as we estimate our own stories, we're gonna go with a time-based estimation, as stated in your linked article. Complexity is another layer of abstraction we don't need as it's useful to be diluted in the team, but we are just 4 with, once again, our own estimation. As stated at the end of the article: Calling them points when they’re really just hours introduces needless complexity
– Stan
Dec 2, 2016 at 9:07

If you are doing Scrum, you should have a burn down chart. It's the tool of choice to visualize your sprint's progress and see if you are going to reach your goal. It will show you if you are ahead or behind your schedule. It's commonly updated in or after the daily standup.

• Hi @nvoigt, thanks for your answer. Yes, we have a burn down chart, but it's based on the points which are base on complexity, so I have the progress through time base on complexity, which bothers us.
– Stan
Dec 1, 2016 at 16:22
• @Stan why does it bother you? It's Scrum standard. Dec 1, 2016 at 16:25
• Burn down charts were removed in 2011 as a framework requirement. It is important to maintain one's knowledge from the authoritative source which Wikipedia is not. Apr 18, 2018 at 11:46
• While an actual chart is no longer mandatory, it's still mandatory to know the data that would go on that chart and make it available to the team. So personally, I still think they should have one because it's the easiest way to achieve that requirement. You are right in that it is no longer mandatory as per the Scrum guide. Apr 18, 2018 at 12:06

Stan, as nvoigt said we use Burndown chart in Scrum to measure the progress.