Almost everything for us is now a
pomodoro . Some time ago we replaced the
per-iteration planning game with on-demand planning
pomodoro s 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.
Thursday, 14 May 2009
Pomodoro galore
Posted by Simon Baker - Permalink
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?
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/
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.
Hi Simon, last question: do your team use the pomodoro technique even for tracking your development effort?
Pietro Di Bello
www.sourcesense.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 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.