Almost everything for us is now a pomodoro. Some time ago we replaced the per-iteration planning game with on-demand planning pomodoros and the end-of-iteration retrospective with a pomodoro retrospective.
Every Wednesday, the first day of our weekly iteration, we kick off with a 25-minute planning pomodoro to give us just enough stories to make a start. We’ve been experimenting with a modified fishbowl format to stimulate the right level of technical discussion and keep energy levels surging. When the board gets short of stories (and the team is in danger of stalling) we run another planning pomodoro to top up the ‘waiting’ column. We keep doing this until the showcase on Tuesday but we’re careful not to end with loads of stories still in progress.
Our estimation is simply: “Is this story less than 2 days?” and the team shows thumbs up or down. If it’s not, the story is split there and then. A pre-planning pomodoro run in advance of Wednesday, looking ahead into the next iteration, helps to size stories appropriately and get the acceptance criteria on the back of the cards. Our velocity is the average-to-date, over all the iterations, of the number of cards that made it to done. This gives us a steadier velocity than summing the estimates of the stories that made it to done in that iteration. We’re not really using the velocity for planning purposes though. We use it to calculate a per-story cost, in £, derived from what was delivered in the iteration and the overall capacity cost for the iteration. From this we can then calculate the cost of any inventory and outstanding technical debt. It’s sobering to see these things in money terms. I’ll blog separately about the simple profit-and-loss sheet we use based on lean accounting and the metrics we watch.
The pomodoro retrospective is conducted standing up. This keeps things moving and keeps people focused. 25 minutes doesn’t provide a lot of scope for variation of activities but we can easily cover our standard format: brainstorming - affinity mapping - dot voting - and agree one action that will improve things. I expect this will eventually get boring so I’m thinking of ways to do pomodoro ‘lets improve this, here-and-now’ sessions that are triggered by a problem just encountered. I guess these are similar to timeouts. Ultimately, the challenge I’ve set myself is to focus these continuous improvement pomodoros on making an improvement that is not borne out of (and therefore constrained by) solving a specific problem. They just focus on making an improvement to get better.
We’re also experimenting with a new board layout that helps us integrate iterative collaboration with designers. There’s some serious thinking to be done here and, to be honest, we could do with a fresh project to try it out on.
7 Comments
On your 2 day story splitting - we are required to make every story's testing user facing. We are not allowed to show results in a database, etc. How do you resolve the issue when a the story testing cannot become user facing in 2 days work or do you care?
All our cards are user facing and driven with acceptance tests, which are typically selenium based (but not exclusively so). TBH .. we've not come across a situation where it's not possible to break a story down into 2 days (or less) and still have it user facing. We iterate using functional depth (read some of Jeff Patton's stuff on iteration) which means we visit a user task many times with multiple stories each enriching the user experience. For example, imagine the user task was a bus. The first story would deliver a grotty camper van. And the last story would deliver a deluxe 60 seater with all the trimmings. The point is every story delivers a fully functioning bus, from cheap and nasty to super expensive.
sounds like a pomodoro based kanban where the WIP is limited based on time, and you're getting in to JIT planning, JIT retros. In Miami we discussed about continuous improvement not necessarily taking in to account the positive, a la appreciative inquiry.
Have you given thought to going to http://ukleanconference.com/
Hi Simon, some questions:
1. You say "Our estimation is simply: "Is this story less than 2 days?" and the team shows thumbs up or down. If it's not, the story is split there and then."
What is the criteria you use, I mean, how many down thumbs will let you choose to split the story?
2. When do you hold the pre-planning pomodoro? You say, before the start of the new iteration, but when?
3. I did not understand cleary how you calculate the per-story cost, and this topic is very interesting to me. I cannot see then how you derived the cost of inventory and refactoring debt.
Thanks a lot, I love your blog.
Pietro Di Bello
www.sourcesense.com
Hi Simon, last question: do your team use the pomodoro technique even for tracking your development effort?
Pietro Di Bello
www.sourcesense.com
Hi Pietro
1. We use consensus. Everyone must agree. We continue to discuss what to do on a card until everyone has thumbs up.
2. Pre-planning pomodoros are usually done on a Friday.
3. I'll blog about this separately in more detail but here's a quick recap. I count up all the cards that made it to done in the iteration (including debt, defects, sysadmin and biz value cards - everything is a story). I know how much the iteration cost, i.e. what we spent in the week (salaries, hardware and software, stationery, sundries, etc). The cost per story is the iteration cost divided by the number of cards that got to done. I then calculate say the cost of debt by multiplying the cost per story by the number of blue cards that got done in that iteration.
Hi Pietro
I'm the tracker and I use pomodoros for my personal tasks. So when I'm completing the tables for our metrics (blog post to come) I use a pomodoro.