Are Sprints Just a Way to Organise Releases?
I’m increasingly convinced that some teams cling to Sprints / Timeboxes because they facilitate release planning. A Sprint = a mini-Release = real simple. However, continuous delivery means these “Sprints” are not real Sprints.
Continue reading
Tag Archives: planning
Continuous Delivery by Default; Timeboxes by Exception
Once I used timeboxes by default. Now I relegate Sprints and such like to exception situations.
Continue reading
Scope Creep v Flexible Scope – Undisciplined v Agile
Bart asked “What do I do when agile is abused as an excuse for scope creep?” with the sub-text “You’re agile so you’re flexible, no?”. I say point out the difference between scope creep and flexible scope. Agile makes changing scope a zero sum game – that gives flexibility without the creepiness.
Continue reading
Little’s Law – the basis of Lean and Kanban
Sometimes I think it helps to go back to basics. And when using Lean Software Development, including Kanban, that means a man called Little and his Law. “Little’s Law” is a fundamental of queue theory and defines the relationship between Work in Progress (WIP), Throughput and Lead Time. It is the reason why Kanban teams try to limit WIP.
Continue reading
None the wiser after the stand up? Wrong stand up or chance to learn
Kim Daubney asked “What to do when stand ups leave you none the wiser”? What you do really depends on why you are “none the wiser”. Do you have a knowledge gap or is the wrong information being shared?
Continue reading
What to do when Estimates go up a lot
You start the Sprint confidently but the burn down chart starts going up. Things are a lot harder than expected! Your velocity is lower than you expected. What to do?
Continue reading
How to spot a Product Owner’s Pet Requirements
Everybody has pet requirements and product owners, being human, are no different. Unfortunately pet requirements are a real risk to software projects. We should all resist these pet requirements and do everything possible to kill them off ASAP and avoid building them. So how do you spot pet requirements
Continue reading
It is ALL Number One Priority / It is ALL Must Have. Not true!
If the customer claims everything on the product backlog is top priority, and by implication must have, then you’ve a bit of an education job ahead of you. You have to get the customer to the point where only one thing is top priority and even “must haves” are sorted into a priority order. There is a good chance some of those “must haves” turn into “would like to have” and in time disappear.
Continue reading
What do you do when the business imposes an arbitrary deadline?
My business stakeholders wanted the product launch to align with a major event in the political calendar – happens to have been the state opening of British parliament. The product was all about politics so launching simultaneously with a major political event made perfect sense to the business folk. The trouble was that this was just an arbitrary date as far as the development team was concerned. What do you do when the business imposes an arbitrary deadline?
Continue reading
Agile has Lists but isn’t Lists
Andrew Vos tweeted (@AndrewVos, 15 Nov 2012):
Hey, guys! Guys. Listen. I found this new agile tool! It’s called “writing stuff down in a list, then doing them one by one”1
Andrew is right, the core of Agile planning is a list. Actually several lists. The product backlog is just a list of high level requirements. A sprint backlog is just a list of tasks to do during the sprint. And, more or less, the team does them one by one from the top priority to lowest priority.
But I disagree with the colleague of mine who said to me a couple of years back “Agile is just managing lists.”
Continue reading