As far as release planning is concerned.
I think should we should be able to plan as many sprints as we want in Kunagi. Now we can plan current and next one only. Planning several sprints ahead is needed to plan release and to draw proper charts.

There are some problems I see with your suggestions. I tend, therefore, to close this issue, but I am happy to discuss your propositions. Maybe we can extract useful information about new features and improvements we can add to Kunagi.

Burn-down

First, let me say something about Burn-Up-Charts. While this idea is thrilling, it is rather a make up effect, not any real change to how Kunagi handles things. In fact, that's exactly what is stated in the first article you linked. In Kunagi, changes in scope are reflected by vertical "jumps", while burn-down (which is essentially the same thing as burn-up) is shown as diagonal progress.

Now, you are correct that there is only a burn-down for the Sprint, not for the whole Project. And although I understand your wish for better release and/or long-term planning, things are not as easy as they might appear. Showing burn-down for the complete project is not at all trivial, because it's size is not fixed. On the other hand, the scope of one iteration is usually well understood. Hence, iteration burn-down will usually be more helpful than product burn-down.

This is the technical reason for the lack of project burn-down. But there is another one. In Kunagi, one of our base principles is to keep things simple and focused on the task at hand. Another is to adhere to the Scrum principle. While there are a lot of agile practices, they are not all fully compatible with each other. We try to create a coherent collection of practices around Scrum. Scrum puts a heavy focus on the current Sprint and it's burn-down. One might introduce a lot of other figures, but I would doubt it's usefulness. In fact, I even think that it might be adverse to Scrum in a whole. Project management in Scrum is encouraged to be done through self-organization and communication. Not "by the numbers".

Finally, some things about project scope: Firstly, many projects have scope that is not well defined. Look, for example, at the Kunagi Project Backlog. It is changing a lot, because it is influenced by many factors: number and commitment of developers, requests from users and even overall progress itself. Many good ideas, that appears as requirements in the backlog, turn out to be not-so-good ideas some months or one year later. So, to what point would we be burning down? Secondly, for that reason I would generally encourage people to put too much effort into estimating and elaborating on stuff that is too far down the road, because those requirements are likely to change in the process of getting there. There is a high risk of work being wasted, because it's results will not be needed later. And if you have highly abstract features at the bottom at the backlog, many of them not estimated, what numbers would you use for the burn-down?

Wrapping up, concepts to do release planning are nice, but they should

• not overpower or pull the focus away from tasks at hand and
• be enough thought out to fit into the overall picture of Kunagi (Scrum methodology and communication over numbers).

The fact of the matter is, by the way, that there are indeed possibilities to estimate (at least for the near future) the course of the project, because Team velocity is established and approximate completion of backlog items is drawn into the Product Backlog. Not that this works in spite of all shortcomings that I mentioned earlier, because it is a projection from now as far as it gets.

About earned value

I have to give you that we do not have an equivalent to earned value. There is also the term business value coming from the same direction. This would indeed be nice, but I regard that as "tools to help the Product Owner prioritize".

About planning Sprints ahead

Planning Sprints ahead introduces some problems with the Scrum methodologies that we avoid when having Planned only one Sprint at a time. Look, for example, at Alistair Cockburn's "iceberg list". Every requirement states, in what iteration is will be done. Who does that? In Scrum, the Team and the Team only may commit to completion of Stories. If I would be a Team member, I would definitely avoid committing to anything even half a year from now. Why? Why would I? Everybody knows that many things might change until then. So it will be basically my fault that it will be different from what I'm promising now (although I could later say "I told you so").

Feel free to elaborate on that idea, but as far as I see it, it is sufficient for the Product Owner to get a reasonable idea of what can potentially be accomplished in the upcoming Sprints using the velocity projection in the current version of the Product Backlog. In fact, it won't get any more precise, anyway, because the farther into the future you try to predict something, the less precise it gets.

I respect your comments on the Project Burn Down, however

A project burn down chart for our team would allow us to at a glance see how many sprints it would take to complete our "current" product backlog of estimated stories. This is not to imply that it is any more specific than that, in keeping with the agile principals.

As new stories are added, pointed, re-pointed, or removed the number of remaining story points left at the end of every sprint could be taken as a data point. As an example,
Sprint Start | Story Points Remaining
0 60
1 42
2 90 ( pointed a couple new stories based on feedback)
3 74

A chart of this with a velocity based trend line starting at sprint 3 (current sprint) would indicate that based on the current known story points and our current velocity, we "Might" finish our stories in 4 more sprints at our current average velocity of 20.

If our average velocity changes, or the number of remaining story points changes, the projected number of sprints to complete all pointed stories would also change.

Would this reduce scrumminess? I don't think so; it won't change the scrum team composition, the priorities of the stories in the backlog, or affect the teams velocity. In my mind it would be a tool that Product Owners could use to help anticipate and pave the way for releases. If I know that my project has X number of sprints to do work and with our velocity we expect to complete all our pointed stories in X+2 sprints, then I know we need to start adjusting customer expectations.

I'd like to point out that you can already see how many Sprints the Prouct Backlog will take, given an average velocity. It is displayed as bars between Product Backlog Stories.

This feature (as well as the visualisation as a burndown chart) requires the Stories in the backlog to be estimated. However, while our projection works with only the hight priority Stories estimated, a burndown chart would require all Stories to be estimated at all times to ensure a reasonable (and not distorting) visualisation.

Having the complete backlog estimated might work for smaller scopes, but I would neither expect nor encourage it to be the case for larger projects.

Such a project burndown would perhaps encourage the team to maintain an always estimated product backlog.

We should have a live discussion on this topic.

Very interesting debate. I think it would be very useful to have a Product Burndown chart. On the other hand, I also agree that to be able to do useful it is required that all the current backlog is estimated and thus incurring in an effort to estimate. The balance is the availability of this chart in Kunagi and each project depends on whether it warrants incurring this effort or not. There will be other projects that do not be so necessary.

regards

So, when it is expected to be present in Kunagi?

Sorry, but we have not scheduled this feature. I have created iss1057 to precise the task.