There are many good ways to run an agile process, but an astounding number of teams do it badly. In particular, they do meetings badly. There are really only three reasons to have a group meeting:
- you want to collect inputs from a group of people in a collaborative way
- you want to create shared understanding
- you want to celebrate something
When it comes to iteration (or sprint) planning meetings (IPM), you want to focus on the first two. If people are lost in their own laptops or cell phones, the answer isn’t to require them to pretend to pay attention, it is to run a meeting that keeps their minds involved.
Having seen a lot of different flavors of agile, here are some of my beliefs on how to run a good IPM. Done right, it doesn’t need to take more than 30 minutes, with occasional longer sessions for pointing batches of stories:
Do it weekly
If you are going to be agile, be agile. There is no reason why you can’t add/remove/change user stories on a weekly basis. Going shorter than a week, in my experience, causes a bit too much chaos for an engineering team, but weekly should be doable for everyone.
Have a pre-IPM
The only way to have a smooth IPM is for the leaders to get organized beforehand. The lead engineer and PM (and possibly the team’s designer) should sit down and review:
- that there are enough defined stories for the week (and then some)
- that the stories are clear (including relevant designs)
- that the stories are in a prioritized order
A pre-IPM will keep the group meeting efficient. The leads can run through the stories, giving the team enough time to ask questions or debate priority, but keeping a pace that keeps everyone engaged and sane.
Write atomic user stories
Velocity is easier to make sense of (less volatile) if you make your user stories as small as possible, and you keep your iteration length to a week. The larger you make your stories, the greater chance your points estimate will be wrong (and psychologically, the slower the team feels). How atomic to go is a judgement call, but a general rule of thumb is:
- if it provides some atomic level of value to the user
- if it can be tested
A user story doesn’t have to be something you would actually ship to the user. That decision (MVP thinking) is entirely separate. So for example, if you need to show the user an editable table with three data points, I would make rendering each data point its own story, and likely make editing the table its own story. However, if I had a dropdown with 5 choices, I would consider that one story — if you had a dropdown with no choices, that delivers zero value to the user. Use your judgement.
Point going in, measure coming out
If you use story points to measure velocity, you want to have done the bulk of your pointing work going into the IPM. Call a separate meeting where you point several weeks worth of stories in advance. Then in the IPM, all you have to do is point the occasional new story.
I dislike the approach of setting a point total as you go into the week. User stories aren’t “in” or “out” of the iteration. There are simply stories you are working on, and (prioritized) stories that you haven’t started yet.
The team should try to be as productive as possible, and only measure points *after* the week is done. Then you can compare the week’s points against previous iterations to see if there are any signs of trouble.
My view of velocity is that it is a canary in the coal mine, not a commitment.
Point as a team, not based on the engineer
Most teams have a diverse set of engineering skill levels, but I believe in setting points based on the overall team’s assessment of complexity, not the engineer who takes on the task. The inevitable inaccuracies should come out in the wash. This aligns to my next point, which is about not assigning stories if you can help it.
Have each engineer give their point estimate at the same time, and then discuss the differences. Go with the higher point estimate if there is not clear consensus, and don’t let any one engineer bully the room.
Don’t assign stories if you can help it
There are benefits to giving engineers broad coverage of the code base. With that in mind, when an engineer is done with a user story, they should turn to the next available story that is in their functional area (a purely front-end engineer would not take on a purely back-end story). You obviously need a prioritized list.
If the work is in part of the code base where the engineer is completely cold, you have an opportunity to do some pair programming and speed up the learning curve. The exception to this is when a set of stories are clearly all tied together. In that case, it is worth minimizing context switching and letting an engineer (or pair) claim them all.
Final Thoughts
I’m definitely a lower-case “agile” person. I believe in minimum-viable-everything, including process. My general problem with scrum is that people have gotten so religious with the ceremonies that they have forgotten the core principles that led to the agile manifesto in the first place. Every company should find a process that works for their culture, but the above has worked best for me. That said, I’m really interesting in exploring the use of kanban, and WIP limits + cycle time measurement, across multiple teams.