Agile Software Development has been an efficient way to develop digital products during the last few years, and it's a mandatory pillar of your Digital Transformation in order for your company to become a great Digital Product Company.
ADAPT Methodology® is a unique Digital Product Development framework to change traditional project-centric companies toward product-led companies!
Society changed and leaders need support in the way how they lead and design their digital product organizations, that is the reason why the ADAPT Methodology® was created, but now let’s get a deep dive into Communities Of Practice if you want to get a deeper knowledge about this topic.
Agile teams from around the world use the planning poker technique to estimate their product backlogs. The Planning Poker in Scrum brings together multiple expert opinions for the agile estimation of a product.
The Planning Poker includes everyone: programmers, testers, database engineers, analysts, user interaction designers, and all other personnel involved in the product. Because these team members represent all disciplines of a software product, they are best suited for the estimation task.
A poker planning or scrum poker session involves product owners or customers, and editors. The session begins with each estimator holding a deck of value-based cards ranging in sequence.
We recommend the following: 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. These values represent the number of story points, ideal days, or other units in which the team will estimate. The product owner or customer will either read an agile user story or describe a feature to the estimators.
The estimators discuss the feature and, if needed, ask the product owner questions. When the estimators have finished their discussion, they each select one card privately to represent or their estimate. The cards are then revealed simultaneously.
If the estimators select the same value, that number becomes the estimate. If their values differ, the estimators discuss their rationale. Those who chose the highest or lowest value should share their reasoning with the group before each estimator selects another estimate card, repeating the process.
The estimators continue the poker planning process until a consensus on the value is achieved. If they cannot agree, the estimators may opt to defer the agile estimating and planning of a particular item, pending additional information.
Most teams will hold a poker planning session shortly after an initial product backlog is written. These sessions, which can take several days, are used to create initial estimates which are useful in scoping or sizing the product.
Because product backlog items – often in user stories form - will continue to be added throughout the product, most teams find it helpful to conduct subsequent agile estimating and planning sessions once per iteration.
They are typically held a few days before the end of the iteration and immediately following a daily standup because the whole team is still together.
The following tips help teams deal with common challenges in poker planning in Scrum:
Watching successful teams during poker planning sessions will clearly demonstrate the three top reasons listed. Poker Planning is a great tool with many benefits, but there are other ways to help improve the process even more.
Small steps that most people miss, can be done to improve the process. Knowing these tips will enable the successful coach or trusted team member, to help their team improve. So what are these nuggets of wisdom?
Too often, agile teams have everyone vote, regardless of their role in the product. Only those actively involved in the story should vote.
Managers usually want the work to take less time, so they often vote very low. However, they have more experience than the average team member. By giving a manager veto power over the team consensus in one specific circumstance, they can then ask the team to consider something that may INCREASE the size.
Never allow managers to give low sizes or persuade the team to decrease its size because their opinion carries too much weight. A manager’s views will act as an anchor and drag the size down as they vigorously defend their position.
Consecutive sizes might be 5 and eight8 if you are using the Fibonacci sequence for sizing (1, 2, 3, 5, 8, 13). An equal split usually takes a long time to resolve, therefore, use the higher number.
In my experience, no one ever agrees to a middle-ground number and usually chooses the top size at the end of the discussion. Using these facts is advantageous and will speed up the process.
Teams commonly get very technical with details when discussing a user story. While this is fine to a certain extent, it should be severely limited. Discussions should not take too long. The people involved in the sizing should already have an idea of the simplest, plausible solution and pick a size based on that scenario.
While many believe that more discussion will make the size more accurate, the reality is that is not true. It is done in part, to encourage teams to just make their best guess and move on. However, there is a distinct lack of precision so the scale is not granular.
Teams often become so involved in their poker planning sessions that they do not realize when some team members need a break. Having an “I need a break” card can be used by someone on the team to draw everyone’s attention to the need for a break.
Using a timer to limit discussions is self-explanatory. Discussions should be restricted to no more than one minute.
After two rounds of discussion, further attempts will not yield greater results and waste time. By choosing the largest size, the team has room to improve and will not be in any danger of running out of time. The biggest problem teams try to avoid is running out of time, so this shortcut should resolve that issue.
User stories should have the answers to the most obvious questions ready. Having answers ready, the team can focus on the size, not gathering information.
Whatever the team picks as a baseline, it needs to be consistent from iteration to iteration. If an ideal day is size one, then all iterations need to use that reference point. If a user story is size one or three, then that needs to remain consistent across iterations.
Sometimes, it is helpful to re-address the baseline and discuss with the team what they believe the sizes truly are. Failure to do this could eventually lead to “size creeping” a term I use when the team mentally changes its baseline over a larger or smaller size over time.
This usually happens when the team cannot meet its commitment for several iterations, even though everything looks more or less the same.
Playing Planning Poker should be a fun, collaborative exercise. Too many teams try to grind it out for an hour or two and forget to enjoy their work. There are many ways fun can be injected into the process. I like to play real poker with the sizes to add fun.
To play, every sized story counts as a poker card, and every five stories make a poker hand. Before starting, everyone tries to pick which hand will be the best. This encourages the team to look at the user stories ahead of time, and then try to guess which set will make a straight or four-of-a-kind. Winners can even get a small prize.
"How can you play Planning Poker with teams that are geographically distributed"? There are likely many options to achieve this. These are a few common options:
Option-1: Chat Window (Tried, but leaves loopholes for biased points selection)
Communication mediums like GoTo or WebEx are used when teams are geographically distant. Once the requirements are clear, the product owner can signal via an utterance to give points, and every member can use chat window tools to enter their number.
Option-2: Webcam (I'm using this one in the current project - Not great fun, But works!)
When using video conferencing to meet with multiple people (Google+ video is a free and popular one), one person runs the meeting. That person says “1-2-3-Go”; after "Go" is said, each team member shows their card on the webcam.
Because the tools were supporting multiple people video chat displays the users in a mosaic/tiles-based form, it is easy to see all the figures at once. However, on a funny note, people tend to show up cards after watching others.
To prevent this, ask every member to hold up their card with the backside facing the webcam. Once the host instructs the team to show their card, everyone simultaneously flips their card over.
Option-3: Planning Poker.com (Good. But you can't change cards)
This website is designed by Mountain Goat Software, the same organization that pioneered poker planning cards. It is a free site that allows the moderator to create the project, add stories and invite people via email to participate in the process.
Any user who clicks on this link sees the story and standard scrum cards. The user does not need authorization to click on any Scrum or post their thoughts on the story’s complexity.
Option-4: Google Docs
This idea is simple: create a spreadsheet in Google Docs and allow people to type their numbers.
Option-5: OneNote
The idea is similar to Google Docs, but MS Office documents also offer live synchronizing and platforms. While usage is limited to the desktop browser, but people also can post their opinions from their smartphones. Users new to OneNote will benefit from this video to learn the program.
Option-6: JIRA plugin
JIRA for Scrum management has a plugin to integrate poker planning within a JIRA UI. More details are available here.
Option-7: Scrummy
Scrummy is a story point estimation game for scrum teams, developed by the Web Chefs at Four Kitchens to allow easier participation by remote team members and to experiment with some new technologies.
Planning poker helps agile teams estimate the time and effort needed to complete each initiative on their product backlog. The name of this gamified technique is planning poker because participants use physical cards.
One of the great things about Planning Poker in Scrum is the fact that brings together multiple expert opinions for the estimation contributing to better estimation.
We enable leaders to become highly valued and recognized to make an impact on the World by helping them to design Digital Product Companies that will thrive and nourish in the Digital Age, we do this by applying our own ADAPT Methodology®.
If you are interested in knowing if you have what it takes to design and build a great digital product company simply take our Digital Leadership Influence Scorecard.
If you want to know how we can help you to start your transformation please check out our: Training.
If you are interested in doing a transformation in your company please check out our: Consulting.