The challenge with estimating agile project starts with the unit selected to quantify it.

Story Points

Story Points are a standard answer to a question about measuring Agile Project. But even if Story Points are well embedded in your organization, measuring by it becomes a major headache very quickly. Teams use it to estimate complexity, managers translate it to hours. The Story Point itself is sensitive to a team assigning it, it does not reflect the circumstances around a sprint and it can be a victim of inflation.

Story Point is a moving target.

But what’s the point?

The primary reason to measure a project is to be able to forecast. What we need to know is the chance to deliver a specific functionality (expressed in story points) within M sprints given the historical data. On top of it, we expect it to give us an insight into the quality of the agile process itself.

The standard way is to look at an average of points delivered, compare it to the backlog and apply it to the future sprints. A more advanced way would be to combine it with a confidence level.

But is all comes short, because Story Point itself is a moving target.

We don’t know what we don’t know

The standard way of quantifying a sprint in story points misses a few very important factors:

  • Work which is done without points, not on a sprint or both.
  • Capacity variations between sprints (people on vacation, unusual sprints during holiday season)
  • Differences in estimation between teams and between sprints (team maturity, points inflation etc.)

All of this can be (in theory) solved by a proper agile process, but how can you bring your process to a higher level if you do not measure it?

The Geigr Index is a percentage, where 100% means that all your work is done with points and within a sprint, and the team delivers exactly according to the plan.

The idea behind Geigr Index is to introduce a statistic, which reflects the quality of your estimations and the agile process itself.

If the index is 100%, you can blindly take what the team commits to in the planing session and use it to estimate the future.

The index has a number of advantages in comparison to the standard measurement of velocity per sprint:

  • It reflects the way team manages its backlog, so it can be used to monitor the process
  • It is not sensitive to sprint velocity differences, because as long as a team anticipates its limitations during the planning session (*)  and then delivers as planned (**)  it is still a predictable sprint, which you can use it to plan forecast the future
  • If teams use different Story Points for the same complexity, it is still possible to compare them, since it is not a number of points which counts, but the ability to deliver as planned.
See the details at

(*) limitations like holiday season, important release requiring supporting other teams or other time consuming actions, which are not expressed in story points

(**) without changing a backlog ad-hoc during a sprint)

Dear Formula 1, please liberate your data

I looked forward to the 6th edition of the F1 Innovation Prize by Tata Communications since I left Austin last year, but unfortunately 2019 competition doesn’t seem to be held.

At the same time, the pace of the innovation on the fan experience side of things doesn’t impress. From time to time “the pitstop predictor” appears on the TV screen but it seems to be all there is, and even that is not on the level we (competition finalists) dreamt about last year.

I cannot know what is the reason behind not having the competition but if I could have a little suggestion: Dear F1, please liberate your data.

Please provide real time access to the telemetry data. Let the community of Formula 1 enthusiasts help you with the innovation. All we need is “For Developers link” in the bottom of where we could find the API and its documentation. Let us experiment, build PoCs and compare ideas in a modern and scalable way. Daily, not only once a year.


We are not selling jeans here

Do you remember this scene from the movie Moneyball when Billy Beans (Brad Pitt) has a conversation with his scouts about building Oakland’s baseball team for the next season ?


Scouts evaluate players using all kinds of poetic terms. At some point they even rate a girlfriend of one of the players (rating her 6) and use this number as a proxy to estimate player’s self confidence…

At that moment Billy introduces the data guy, and the rest becomes history…

When watching it, my one track mind kicked in and I started getting flashbacks of all  software project discussions I ever took part in. Always fun. All those people using all kinds of poetic terms trying to estimate the complexity of software.

Estimating software is hard. We never do the same thing twice, people in the dev team change, no two customers are the same etc.

However, every day, every software project generates lots of data. Code commits, test results, issue updates, customer support items, testers feedback you name it. Wouldn’t it be great if we use this data to evaluate and estimate software projects ?

we are not selling jeans here“… Say hallo to

Making Agile measurable again

My love-hate relationship with Agile/Iterative software development goes back to 2001 (Extreme Programming-RUP-Scrum). All those years and projects led me to a funny conclusion that Agile is very much like Democracy.

Agile is the worst way (to control software project), but we do not have anything better.

Agile works very well, as soon as you have a team and an organization experienced with it. As soon as everybody knows the process well, and all aspects of CI/CD are successfully introduced everything is great.

Before it happens, however, there is this period of “almost”. The time when all things are moving fast already, but the control is still to be found. Everything is based on some opinions. Opinions expressed during a stand-up (“…almost all my items are almost ready…“), statements during project meetings (“…I’m almost sure we’ll make the release…“) etc.

The problem is that we are in this “Before state” 90% of the time.

However there is also good news. Agile projects have large data footprint. Everything what happens there is a data entry somewhere, in the source code repo, in the issue tracker, deployment log, test log etc.

The collection and interpretation of all project data takes time and skills, so it is rather difficult to do it frequently, or for multiple projects manually. But… But what if we look at it as a data problem ?

I believe that to take full advantage of Agile, it has to be made measurable first. And not with a simple burn-chart, but by combining as much project data as possible, by applying data analysis continuously, and by visualizing it from different perspectives for different stakeholders.

Say hallo to

Screen Shot 2018-12-29 at 16.10.51



Competition mode off, business mode on

I’m leaving Austin without the prize, but with a lot of great memories and new experiences.

James Gough took well deserved 1st prize and my concept focused more on data and architecture came short on the visual side.


The level of all entries was very high making it a very close call. The fact that my solution as concentrated more on the backend, feasibility and architecture got to the final 5 out of > 300 entries in the UX oriented competition makes me really happy.

I was very glad to hear from Roberto Dalla and Andrew James that as engineers they preferred my concept. And my chat with James Allen, who found predictive aspect a great idea, made my day complete.

The idea to liberate F1 data, create community around it and stimulate ongoing crowd based innovation couldn’t out-weight the visual side in a competition built around UX, but I’m glad I had a chance to talk about it with some of the most important people in my favourite sport.

And now going back to the normal world imagine you can visualize and translate your project like this in your business environment…

To be continued 🙂