What is the shortest sprint planning meeting you have ever walked into?
For me, it has to be one that went like this:
Developer 1: Ok so let's keep this short so that we can get back to work Developer 2: I agree, this place has way too many meetings this days Developer 1: (Laughs) True true Developer 1: So you will do the backend I do the frontend Developer 2: As we always do Developer 1: Awesome meeting over! Chencha : But what will be done in the sprint? Developer 2: What is on the TOR doc
At that moment I thought they were playing a prank at my expense. Sadly, they weren’t. As it turns out they did not know what to discuss on this particular meeting.
On this entry I will be sharing some of the discussion points that I have felt led to a more lively sprint planning session.
Break down requirements to user stories
Unless you are one of the lucky few who work with clients who understand agile, you are probably stuck with a legally enforceable TOR. Still no need to despair, we can still recover.
Use this time for you and your team to actually break down the massive document to user stories. Pin the stories on the board or trello. Depending on what your team usually uses to visualize work.
Use planning poker
Planning poker is a technique where individual developers give their estimate by first writing it down in private and showing it to the rest of the team concurrently. This ensures the estimators don’t influence each other.
Once the estimates are made, don’t just stop there. Ask the person with the highest or lowest estimate why they think the item is of that size. This practise should elicit some discussion within the group.
In the 80’s, professor Noriaki Kano came up with a model that classified customers preferences. Basically there are features that the customer just can’t do without and there are some that the customer wouldn’t know they want until you show them. You must weigh the features you aim to develop on this scale.
Have the team discuss the project and distill the objectives of the project.
Once this is done, the project will achieve efficiency advantage in the trade-offs that they will inevitably have to make.
Break down user stories into tasks
User stories are rarely small enough to code. This meeting presents a great opportunity to discuss the tasks that make up a user story.
Take the case of this user story.
As a customer I want to search the store So that I can see what is available
Now that story can be broken down to
- Install elastic search
- Connect elastic search to laravel
- Write endpoint logic for the search term
- Return response as json
- Write html to display the results
Developers can deliberate and come up with the most exhaustive list of tasks possible.
Determine velocity to use
The general rule of thumb is to use the last iterations achieved velocity for this sprint. This meeting presents an opportunity to review the rule and see if it makes sense in the current context.
Respect the Timebox
The purpose of this entry was to discuss how to make your meeting more lively. However if you push it too far, the team may not look forward to the next meeting.
Ensure to state how long the meeting will last before it starts and respect that timebox, no matter how fun or engaging the meeting becomes.
How do you liven up your own meetings? Talk to me on the comment section below or on my twitter @jchex https://twitter.com/jchex