Otto's dashboard

Thanks, Chad. Very interesting. A bit different to what we're used to, but will try it out. I'm used to thinking that iterations and velocity are linked to releases. We are used to working in 1/2 month cycles (to not release over month ends at companies where they freeze releases). When we plan, we say that our velocity is x (yesterday's weather), so we commit to x points for the next cycle and the customer can choose x points to be done.

I do believe that there is some value in releasing on every cycle. It sometimes makes planning a challenge, but we've not come across a case where we could not release. Yes, on the odd occasion, we have to "hide" an incomplete function.

We agree with the fact that chores and bugs should not be part of the velocity. However, we think that estimating them is valuable because it still influences how much we can do in a cycle, whether chores or not. We still plan chores (we know about them when we start our cycle), and we also know that they do not (directly) add business value and should therefore not count as part of the velocity.

For example, we are building a website and had to change the way we render (using pure Seaside, moved to Magritte). In a way, it improves the system from an error handling perspective and paves the way for other enhancements (like adding history at a generic level).

We saw this change as a chore because it is difficult to explain this to the customer and we were willing to lower our velocity (*real* stuff a customer can see).

Any ideas on this thinking? Does this imply that we are doing stuff that the customer did not ask for & we should be convincing him/her that it is necessary, which implies explaining exactly why we are doing it?