Time of course cannot be stopped. It wanders on, sometimes wearing 7-mile boots, sometimes it just stomps along the countryside. It always sees I have a shortage of it, so time apparently is a commodity as well as a flow.
A Sprint of course is also time, it is a time-box, an awesome remnant of days gone RAD. Useful, yet underestimated. What I notice is that my client has a lot of trouble with it. Especially with the concept of not being able to prescribe what we as team will put in it.
A lot of people ask me for a time-planning, both on the user side and on the client side.
They try to get me to predict how much time we need, and of course I am duly reserved in giving them that prediction. I don’t have a glass ball that tells me what is coming (if I had I would be as rich as Richard Branson and I would not be a meagre Agile Coach)
My problem is that the client I work for has a too traditional view on the concept of predictions, If I tell them I need another sprint, they will keep me to it, they will tell me I “promised” to deliver their product in an extra sprint.
Today I told them I will at least need another two sprints to give the about 85% of the functionality their users want. His first reaction was “but you promised the functionality would be done in December”…do people even look into Agile and Scrum when they ask us to use it?
Anyway, we have been ambitious and took on about the same amount of work this sprint as last sprint. Last sprint was successful in that, yet there were still a lot of things we found out and a lot of delays due to interfaces that should have been there a long time ago.
Now I still have to impress on the team to use the sprint backlog. They seem to have trouble with doing that consistently.