Posts Tagged ‘agile metrics’

Shall I split my stories? Yes… I mean No!

Marcin Niebudek,

There is a story card on our wall estimated to 8 points. It’s so easy to tear it down and put two new 3- and 5-point cards instead of that big one. Cool, we can even move one of them to the next sprint. No, no, no…

But wait there is another story in our backlog. This one is big… No problem – lets split it into smaller functionalities. Yes… and yes!

So what’s the point? Is there a problem in splitting stories anyway? The short answer is “yes and no”. It’s because the problem lies not in splitting stories, but in the moment when we do it. There are usually to points in time when we think about dividing stories into smaller parts: release/sprint planning and the end of current sprint.


This is the moment when we think about stories before we start implementing them. We choose what is possible to do within the planned period of time. We gather detailed information about stories that should be implemented first. This is the moment when we try to plan the work that fits into our capacity usually driven by some observations of our recent velocity and other factors.

At this point we may find some stories to be too big to fit into the sprint, but we realize that we can split them into smaller independent parts that are still able to bring value to our clients. We choose more valuable stories and leave the other for a better time or even get rid of them. This is where I say YES to splitting stories.

End of sprint

Next time we tend to think about splitting stories at the end of our sprints. This is caused by one reason – we just can’t finish the story by the end of the sprint. We thought we will, but (again) it wast one story too much. Actually we have it almost done. And this “almost done” tempts us to split the story, leave the finished part in the current sprint while moving just the unfinished chunk into the next timebox. Hurray! Our velocity, charts and metrics have been saved once again!

This is the moment what I say NO to splitting stories. Story should be either fully completed or moved to next sprint. And yes, velocity should drop this time. This is the only way to spot the problem in the long term. Ok, it’s not a problem when it happens once. But if we will break down stories at the end of the sprint regularly to keep our velocity untouched then we may miss the root problem (there will be no sign of it, except for a not so happy face of our PM/SM who needed to tell our client about yet another unfinished story).

The root problem of unfinished stories may be:

  • (most likely) wishful thinking – we keep thinking that we can do more this time and load our sprints with too much stories
  • too short iterations – the amount of features for the increment is good (less of them would not give any usable product) but we try to implement them in to short iterations, so maybe one week is to little and we should switch to two weeks
  • inaccurate estimations – if we have lots of unfinished stories every sprint this means that those stories tend to take more time than we thought and if it keeps happening then we should rather reestimate some of them and try better understand what they are about

So think about when you usually split your stories? Maybe it’s time to look deeper into your process.

Getting the Most From tinyPM’s Project Tracking

Marcin Niebudek,

tinyPM provides at the moment several ways to track project’s progress using different types of charts:

  • project scope burndown chart (3 types)
  • project budget tracking chart
  • iteration scope burndown chart (based on story estimates)
  • iteration scope burndown chart (based on task estimates)
  • iteration scope burndown chart (based on reported time left on tasks)

Those charts are driven by four types of data available in tinyPM:

  • effort, on the user story
  • effort, on the task
  • time spent, on the timesheet activity
  • time left, on the timesheet activity

All those elements are optional to use and every user can choose for herself if she wants to use only some of them or all. You will find a cheat sheet with a summary on all tinyPM charts in our documentation at:

Entering each one of those elements provides different level of insight into project state, so let’s have a look at what can we see in tinyPM by providing each of that data.

User story estimated effort

You can enter estimated effort for every user story. This is the most important and most commonly used number in tinyPM. Story estimates allow planning, are used to calculate average velocity that tinyPM suggests as capacity for newly created iterations (planned velocity field). Finally story points drive all project scope charts, iteration burndown based on user stories. Story points are also used for drawing scope series on budget tracking chart.

tinyPM Backlog

We’ve been posting some information about types of project scope charts available in tinyPM in the article Burning Down, Climbing Up, but let’s recap some key points from the tinyPM user’s perspective.

Project scope chart based on total effort. This chart start with the value of total estimated effort entered for all stories in the backlog. Every completed story (all tasks completed) burns this chart down (blue line). This type of chart contains also the green line calculated from planned velocity entered for each iteration. This type of chart never goes up.

tinyPM - Project scope chart based on total estimated effort

Project scope chart based on initial effort. This chart starts with the sum of estimated effort entered for stories created before any iteration is created. For each iteration we calculate currently estimated effort for all user stories. This means that if any story is removed during some iteration then the chart will fall down faster, but if some stories are created during such iteration (after the start of the project) then the chart may even go up (if stories added are worth more points than stories completed during that iteration). Effort completed for each iteration on this type of chart is calculated using the following formula:

effort left (real) for iteration N = estimated effort of stories created until iteration N – effort completed by iteration N

tinyPM - Project scope burndown based on initial estimated effort

Project burnup chart. This type of chart is the easiest one to use as it starts with zero and every story completed during each iteration pulls the effort completed line (blue one) up by the number of story estimated effort. All changes in total scope of project (stories added or removed during project) are represented by the additional series of total scope (gray line). If all stories are created before initial planning of iterations then the gray line goes up at the beginning and and stays constant during all iterations. However if any user story is added later in the project (and has estimated effort defined) then this line goes up and the whole point is that both blue and gray lines meet at the top right corner of the chart at the end of the project.

tinyPM - Project burnup chart

Iteration burndown (“User stories”). This chart is similar to the project burndown based on total effort. It starts with the total estimated effort for all stories added to the iteration. On the day when user story is completed (all it’s tasks are completed), the chart is burned down. This means that this chart works well for projects where stories are relatively small within the iteration and are quickly completed. Otherwise this chart may stay unchanged until the very end of the iteration when all the stories are finally completed within one or two days.

tinyPM - Iteration burndown ("User stories")

Effort on the task

You don’t need the tasks estimation if you have small stories that can be completed within one or two days. In this case estimates on stories and iteration burndown based on those estimates are totally enough to track project and iteration progress with a proper level of detail.

tinyPM - Taskboard

However if you stories get bigger and you like to define more tasks for each story, then you may want to start tracking tasks instead of stories. In this case tasks can use different scale of estimates than stories (defined in project settings page). This gives a possibility to:

  • estimate tasks using relative scale like story points
  • estimate tasks using time units

If you only want to escape the trap of big stories completed mostly at the end of iteration then the only thing you need is to have more detailed tasks in those stories. tinyPM is able to present two types of iteration burndown chart based on tasks.

Iteration burndown (“Tasks”). This chart may work with tasks without any estimates. If tasks estimation is turned off then all tasks will be treated as even (assuming they are small enough to be completed within a day). They burn down they chart when they are completed. Additionally each task in progress is presented as the yellow area on the chart so that it’s possible to see if a lot of work is in progress but not completed. If the tasks are estimated, then the estimates are used to calculate the burn rates on the chart and bigger tasks burn it quicker than the small ones.

tinyPM - Iteration burndown ("Tasks")

Iteration burndown (“Effort left”). This chart (apart of task estimates) requires entering time left on tinyPM’s timesheet. However if you don’t do that and provide only estimates for tasks you will notice that it will look like the one based on “Tasks”.

Time left on the timesheet activity

Time left comes from Scrum methodology when it’s declared every day for each tasks in Sprint. Iteration burndown (“Effort left”) starts with total estimated effort of tasks. Thats why, if you plan to use time left from timesheet, then task estimations should be also done using time units. After that, for each iteration day, all time left values are added up to calculate total time left to complete iteration.

tinyPM - Iteration burndown ("Effort left")

This type of chart may go up if some day during the iteration we find out something that makes completing the task impossible withing the initially estimated time. At that point we enter higher value of time left for such task in the timesheet. So this chart to work properly requires both – task estimation and timesheet entries with time left for those tasks.

Time spent on the timesheet activity

Time spent entered in the tinyPM’s timesheet is used only on the budget tracking chart. Also the story estimated effort is used in this type of chart to calculate the scope line (blue one). Total effort entered for all stories becomes 100% of scope on this chart, while budget (in man-hours) entered for project (on project settings form) is used as 100% of budget (red line).

Each story completed burns down the scope line while, each hour entered as time spent (on timesheet) burns down budget line. More on budget tracking idea you can read in the article “We’re in the Right Truck!“.

tinyPM - Budget tracking chart

tinyPM - Project settings form

Burning down, climbing up…

Marcin Niebudek,

tinyPM 2.1 introduced three types of project scope charts. We would like to write few words about differences, advantages and disadvantages of using each of them. We will use all three types of charts on the same project data, this way we can better compare the information that can be read from them.

Burndown chart

(with initial project estimation as a starting point)

Burndown (type I)

As you can see, the project started with a backlog containing stories worth about 50 story points in total. When we use the initial estimation as a staring point we simply put the total backlog effort on the chart and each following iteration we mark how much effort there is still to be burned (blue line) and what is the expectation (the green line).

The green line never goes up because this would mean that we expect negative velocity. However the blue line may go up in one case, which is a feature creep.  In other words, the line goes up when at some point of time (T10) more new stories get into our backlog than we can actually complete. This way at the end of the iteration we have more effort left than we had at the beginning.

So we can instantly see the feature creep effect using this type of burndown. But what can we say about our team’s activity between T10 and T14 or even T20? Did they do anything? Iterations where passing by (green line continuously heading down to the level zero) but we cannot see any significant move on the blue line. Does it mean that the team did not do anything, or that the backlog got as many user stories each iteration as we could complete. Actually it may be each one of those explanations. So the point is, that with this type of burndown we don’t know that exactly.

Finally when the green line hits the zero level we can see how late we are.  In our scenario the project was supposed to be finished by the T14, but at that point the team was still missing over 30 points (new stories not included in the initial scope) and the distance kept growing.

You may say this project was in a deep trouble, but we intentionally chosen such data, because when everything goes well and the lines dance close to each other, there is nothing interesting to observe and the devil is in the details. What is so valuable about burndown charts, is that they can quickly warn us when some bad things start to happen. This project could have actually be rescued somewhere between those T10 and T14 points.


  • simple to draw even on the white board
  • can show a feature creep
  • can show the point where the team loses the ability to actually complete the project


  • doing nothing and doing only enough to balance a feature creep looks the same on this kind of chart
  • cannot read the velocity out of this chart
  • your backlog needs to be estimated at the beginning, otherwise you will soon cross the zero level (which will look odd)

What types of projects is it good for:

  • good for projects with some initial vision represented in the backlog and estimated at the beginning (at least as the epic stories)
  • good for projects with fixed-price contract as then we usually have an initial estimation and we want to watch it burned according to a planned velocity

Burndown chart

(with total estimated effort as a starting point)

Burndown (type II)

This type of chart is recalculated each time it is viewed and the burndown always starts with the total currently estimated effort for all backlog items. So even if the project stars with about 50 story points, when we take a look at it after few iterations it shows current total which may be for example 80 points.

Here we can only observe the relationship between plan and execution. We assume that stories may be added to the backlog at any point of time. We may even start with few stories. Until the blue line stays under the green one, everything is fine. If we accept all those new stories (by simply extending the budget or by working based on T&M contract) then at the point T10 there is no trouble in our project – we’re still doing fine having velocity higher than expected.

At T14 we can see that the development stopped for some time. Probably at the point of T14 it reached zero (and maybe has been released), but later the velocity started to decrease (blue line above the green one).

On this type of chart both lines always go down. It does not tell anything about the feature creep in the project, but only about the changes in the team’s velocity.

The last observation that we can make with this chart is that at T29 planned effort reaches zero while there is still some real work to be done. This means that even with all those new stories we should have finished at that point and now we’re getting late.


  • you may actually see the changes in team’s velocity in the project
  • does not require any initial estimation, nor the fully populated backlog


  • hard to maintain on the white board (requires recalculations for the past iterations)
  • feature creep may not be seen
  • treats all stories as “must haves”

What types of projects is it good for:

  • as it does not require any initial estimation it’s best for some research projects or exploratory work where stories are invented based on the results from the recent iterations

Burnup chart

Burnup (type III)

This type of chart actually climbs up. It also introduces the third series (gray line) which is the “current total effort”. It combines advantages from the both previous burndows and at the same time does not have their disadvantages.

We start the project with zero completed and planned effort. Total effort may start also with zero or it may start with some initial backlog stories estimation. The goal is to reach the “total” gray line with the blue one, so actually build all those planned features.

Here we can clearly see both – the velocity of our team (on the blue line) as well as any feature creep by looking at total effort line (gray one). If the gray line goes up, then stories are being added to the backlog (or re-estimated with some higher values) . When it goes down, it means the scope to reach gets smaller.

At the T10 we’re doing fine in terms of team’s velocity but at the same time our project scope gets larger. It’s time to decide if it’s something wrong or if we accept those new ideas. At T14 we’re done with some part of our product, and it looks like we’re are done just in time. However there is still lot to do (for example for release 2.0). T28 is the point when we actually planned to reach the goal (green line meets the gray one), but somewhere between T14 and T28 our team has lost it’s initial velocity and now we are still missing about 20 points (blue line still not there).


  • shows most of the interesting patterns in all kinds of projects
  • easy to maintain even on the white board


  • none that we know of unless you find this chart being painted upside-down ;-)

What types of projects is it good for:

  • all types of projects

We hope that those examples will let you better choose the best type of chart for your project. We are waiting for you suggestions or any other ideas on how to visualize the project status even better.

Sprinting on a long distance

Marcin Niebudek,

I find SCRUM’s “sprint” a very intriguing name for an iteration. In the heart of agile development there is continuous delivery of a working software. To do that we time-box software development into iterations / sprints.

They have their rhythm and require different kind of discipline from our team. We become sprinters who continuously plan, test, implement, evolve architectures, deliver, improve the process, celebrate to finally be back in the starting blocks to launch another sprint. We do that iteration by iteration.

Can sprinter be a long distance runner?

A very common technique in agile projects is tracking team’s average velocity. It’s said that it should stabilize after few initial iterations on some level. This is also called finding a sustainable pace for a team, which in short means that our team members commit to just enough work to become productive without burning out to early at the same time.

I’m not going to convince you here why a sustainable pace is a good thing and why a tired developer is not going to be efficient and creative. It’s the opposite that always intrigues me in the name “sprint”.

When we sprint, we put all our energy to run a short distance (a single iteration) the best we can. However we plan our efforts differently when we are about to run a marathon of 20 iterations. So how long are we able to sprint and keep our average velocity constant?

Velocity loss

Is there a point at which the team will start to loose it’s velocity? Well the answer might be that that’s where the sustainable pace comes to mind. We do not overcommit and we in fact stop sprinting at the maximum available velocity that we can achieve to sustain the pace.

Sustainable pace or sustainable undercommitment?

So how do we distinguish sustainable pace from sustainable undercommitment? Where is that point that we know we should not commit to more work as a team without being accused of just not being willing to do more while hiding behind a very nice term of “sustainable pace”?

My answer to that is great people, trust and transparency – all being the key parts of agile development. What is yours? How do you keep it at the level everybody accepts?

We are in the right truck!

Marcin Niebudek,

At the beginning I owe you a small explanation to that strange title :-) I would like to write a few words about project tracking. It will be mostly a translation of my post from Battle for Agility which is a blog where I write in the first place, but as that one is written in Polish I thought this particular post might be interesting also to those of you who don’t read in Polish.

But let’s come to the point – my bizarre title. Some time ago I was working on a project and before each new iteration I used to hear “We are on the right track!”. As you may expect it had as much in common with the real situation as my title.

How does it look to you (the image below)?


Right… looks like the common burndown chart. Well maybe not so common because it’s expressed in percent instead of story points, but this will become clear in a few minutes.

So based on that chart one might even tell that we are indeed on the right track. Let’s assume that this chart was made for some project which was started with a fixed-price contract. Somehow we’ve created the base estimation for that project which included 50 pts – this became our starting 100% (scope). If we had a fixed-price contract, then we had a fixed budget. But not the money is important here, only the number of man-hours we had in the budget based on that contract (we’ve put X our developers for Y weeks/iterations into that project). Let’s assume it was 500 man-hours and it also became our 100% (budget).

Now, how about having our burndown look like that?


Right – not so good anymore… but everyone thought it’s going to be perfect and in fact in their minds they thought the burndown would look rather like this:


So where am I heading to? When we track only a scope burndown (or if we only track whether our team meets the assumed velocity level) there is always a chance that we will miss the fact we’re far away from our “track”. It’s just the way a burndow with only variable works. It always looks more or less correct until it falls down, because we only expect the falling trend and we react only when that trend is disturbed. But what we don’t see is how it relates to our contracted budget and this is especially true when we estimate in story points.

This is even so if we have current scope burndown vs. some assumed or planned burndown but still expressed only in story points and base on only estimated values.

That is why we use  percent values. This way we can put two different scales tracked in our project on a single burndown chart. If we recalculate our budget expressed in hours/money into percent of budget already used and we do the same with the delivered scope expressed in story points, then we can tell not only if we are going to finish within a given time frame (burning down the scope), but also if we’re doing it within a given budget.

We’ve finished stories worth 10 pts in total which is 20% of our project scope, we’ve also worked 125 hours on those stories (real working time, not estimated values), which is 25% of our budget. Now that is the information that may warn us – we’re spending 5% more then we’re delivering. If we would not control the budget, those 20% of burned scope might have not look so bad right?

I think this might be a very simple to calculate and yet very accurate way of tracking project progress. Based on those two correlated factors we can tell whether we are truly on the right track or not. Finishing on time is simply not enough.

I would also like to note (based on our recent discussion about tasks estimation at LinkedIn) that the approach presented here works well when you have stories estimated in points and you don’t even estimate tasks. No estimations in man-hours needed tool to be able to track time and stay up to date. I’m sure that the stakeholder seeing the red line falling down faster than the blue one won’t wait long to react :-)

PS: We plan to provide such a way of project tracking in one of the future releases of tinyPM.

Are you brave enough not to estimate your tasks?

Marcin Niebudek,

I think tasks estimation and tracking progress based on story task estimates almost always leads to tasks becoming pseudo user stories within large and overestimated real stories.

When estimating stories we encourage developers to use points and to show only relative size within the whole set of stories. I think it’s much harder to do with specific, usually technical tasks – you start judging between activities of different type, for example implementing some component and designing user interface. In other hand estimating tasks quickly falls back into estimating in man-hours and might lead to tracking people instead of real progress.

Surprisingly when implementing our tool we found the feature request “Tasks estimation” to become the most wanted one, while we want to encourage our users to rather split stories into smaller functional parts and use tasks for stories as some kind of to do list for developers.

So what works for you? Why do you want or need to estimate tasks within stories?

For project tracking? You can track stories. The story is done when all tasks are done. When you have small stories you don’t need to wait long for visible effects even if you iteration is a month long. For making sprint/iteration burndowns? You can do it successfully with stories, but again you need them to be small functional parts not epics. If you have two big stories for one month then agreed, you burndown made of stories won’t look any helpful.

Or maybe somewhere down there you need those man-hours and strict task assignments for your manager/boss? So are you brave enough not to do that :-)?