Iteration Planning Meeting (IPM)

Who: Entire Development team, Designer, Product Manager How long: 1 Hour or less Facilitator: Product Manager Goal: Communicate the upcoming work that needs to be done from organized backlog for the next iteration (1 week). Remember only to focus on work that is directly tied to the hypothesis defined for the product.

Key Points of Focus: 0) Make sure to focus on where you just came from and where you are going. 1) SHORT, Keep the meeting short and focused.

• 1 hour at MAX

• Assign someone as the offline referee if you need to and rotate them. The offline referee is someone who can basically say, "Timeout, can we offline this? I will capture it and we can talk about it after the IPM".

• If you find that you do not have enough work for the IPM, be transparent about it and work with the technical lead to translate the user's needs and stakeholders asks into stories related to the current hypothesis.

2) Create a shared understanding for the stories this week

• Start by looking at any stories in progress. This gets everyone synced fairly quick with where the product is.

• Work your way from the top of the backlog, and go through each and every story. These should have been prioritized earlier and should begin to tell a collective story.

• Ensure that all the needed pieces of data are in the story. Sometimes a story needs more details than the gherkin and acceptance criteria. Miro boards, whiteboards sessions, conversations from users etc.

• Make sure not just one person has access to it, but instead everyone should have that info readily available.

• EVERYONE on a team should understand when a story is finished.

• Ensure that stories are small (We like to use a gut check of no greater than a day's worth of work) we want to deliver stories daily.

• Everyone on the team needs to understand the stories, as this is where knowledge silos can quickly be made, if not kept in check. SEE pointing.

3) Confidence Check with pointing I have found pointing to work best, not as a means of estimation, but rather as a means of gauging shared understanding. Pointing is a QUICK way to check the confidence of the team based on their experience, or knowledge on a topic in relation to a story. I have found that when using points which is not based off of time, humans are terrible at estimating in regard to implementation and are usually wrong. Instead point based off of confidence on a scale of 0-3. 0 - Get it for free 1 - Know exactly how to implement something 2 - Some unknowns exist, but is something that can be worked on 3 - Do not know how to begin the story, and need to research or have a conversation Tips: Do not discuss points before you point, as you do not want to create a bias or a false representation of someone's confidence.

• An example of a way to point is to 'roshambo' (Paper Rock Scissor timing) and have everyone hold out a digit with their fingers.

• Sometimes higher points can be a sign of a story that is too big, so keep it in mind.

• Sometimes lower points can be a sign of a story that is too small.

• If an entire team is voting a 1 for instance, and a team member votes a 3, sometimes that is a great sign of pairing session that needs to occur. Pair the person who voted the story highly with someone who voted lower.

• When there is parity amongst the team in regard to points, it needs to be discussed and then re-pointed.

4) Chores Chores can represent technical debt that needs to be cleaned up, so try and figure out ways to not have a lot of chores but instead, infuse them with feature stories

5) No more than 2 weeks of work in your backlog

• This comes down to focus.

• There will be always features to implement, but it is up to you to decide which ones will be worked on next.

• Running lean is incredibly important and a lot can be said on this topic ('The Lean Startup' by Eric Ries).

• Keeping track of what all needs to be done can QUICKLY be mentally taxing and you need to be sure to enable yourself to keep track of as much as you can.