6

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 ?

Community
  • 1
Stan
  • 171
  • 5
  • 1
    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. – jessehouwing Dec 01 '16 at 09:39

3 Answers3

3

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.

nvoigt
  • 8,475
  • 19
  • 34
  • 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 01 '16 at 16:22
  • 1
    @Stan why does it bother you? It's Scrum standard. – nvoigt Dec 01 '16 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. – Alan Larimer Apr 18 '18 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. – nvoigt Apr 18 '18 at 12:06
3

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.

Nathan
  • 1,265
  • 1
  • 10
  • 10
  • 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 01 '16 at 16:27
  • 2
    @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? – Nathan Dec 01 '16 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 02 '16 at 09:07
2

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

You can read about it here https://www.mountaingoatsoftware.com/agile/scrum/release-burndown

Your engineering's brain is right and you can calculate as you have mentioned 3 Story points per day per person. Notice that the Burndown chart is visual and makes it much easier for you to follow the current state, but it also allows you to look at the trend in the Sprint.

Another thing to mention, in Scrum do not look at how many Story Points one developer needs to burn per day, but ALWAYS observe the entire team as a whole. Commitment is made as a group, Velocity is measured for a whole team. Some people are faster, some slower, but you all make the software together.

Vladimir Rodic
  • 145
  • 6
  • 2
    At risk of Mike Cohn overload, here's another article from him about the relationship between story points and time and why they're connected, but not the same, since the poster specifically asked about that point. https://www.mountaingoatsoftware.com/blog/story-points-are-still-about-effort – Daniel Dec 01 '16 at 14:24
  • We do have a burndown chart, but as I answered to @nvoigt, it's based on points which are complexity based, so I'm looking at a graph which tries to relate complexity to time ... Which is what bothers us. You've got a point on the "entire team as a whole" though. – Stan Dec 01 '16 at 16:25
  • @stan you should not be relating complexity to time. They do not equate directly and the standard deviation for each complexity point to r time makes any such calculation imposible. – MrHinsh - Martin Hinshelwood Dec 01 '16 at 19:36
  • Burn down charts were removed in 2011 as a framework requirement. It is important to separate common practices from the actual framework within which they are used. Mike Cohn and MGS spread such common misconceptions. – Alan Larimer Apr 18 '18 at 11:48