Planning Poker Via Skype
Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud.
- Planning Poker® in Scrum brings together multiple expert opinions for the agile estimation of a project. In this type of agile planning, we include everyone from programmers, testers and database engineers to analysts, user interaction designers and more. Because these team members represent all.
- An example of this is story point estimating or Planning Poker. Microsoft Lync Polling can help bring the team together even if they are, in reality, very far away from each other. In this post I am going to walk you through the process of using Lync for story point estimating.
- Skype is a good tool for organizing conference calls. Since it's a popular service, you're likely to find people you want to add to your group call using the app. It's also available on multiple platforms, and calling other Skype users is free. This holds true for individuals and businesses alike.
Texas Hold 'Em, Seven Card Stud. If you've just come back from the Microsoft Inspire conference in Las Vegas, you probably know a lot more about those kinds of poker than I do.
I've never played poker in my life, which is probably why Gus Gonsalez always invites me to join his poker game at MVP Summit every year. (At least it's not strip poker, Gus).
But there's one kind of poker that I do know, and that's planning poker.
Planning poker is a team game for estimating work. It's often used by Scrum teams during backlog refinement workshops or sprint planning to estimate the size of product backlog items. In my Dynamics 365 projects, we play planning poker to estimate the complexity of our epics, user stories, chores, bugs and spikes.
As I see it, there are three main advantages to using the planning poker game for estimation:
The development team all get to learn more about the upcoming work. Planning poker is a good opportunity for everyone to ask questions, test assumptions, and learn the details about work that we're just about to start. I prefer just-in-time requirements analysis instead of specifying all the details many months in advance.
We get diverse perspectives in our estimates because development team members who specialise in analysis, design, configuration, customisation, development, integration, quality, and deployment all get to contribute towards the estimate. I've found that this leads to much more accurate and better-adopted estimates than a single architect estimating all the work in a waterfall project's analysis and design phases.
We're estimating the work as we learn about the system we're building. We play planning poker frequently, at least once every sprint through the course of the project. That's great because it gives us a chance to use what we're learning as we build the system and use that experience in our next round of estimation. That's much more useful that estimating everything at the start of the project when we've got no experience of building this system.
What I like about planning poker is that the whole Scrum team gets to participate in the game. The product owner is there to answer the developers' questions about the requirements. The product owner might be joined by subject matter experts from the organisation but neither the product owner or the SMEs get to play planning poker.
Only the people who do the work get to estimate it. That means only the development team gets to play planning poker.
Do business analysts play planning poker?
On the Scrum Dynamics podcast, Dermot and I debate whether business analysts are subject matter experts representing the product owner -- and therefore don't estimate the work -- or whether they are analysing the requirements for the dev team -- and therefore should estimate the work.
I guess it depends on the type of business analyst you're working with. If they are familiar with Dynamics 365 and are involved in configuration and customisation in any way, then I think they are part of the dev team. If they are refining the backlog but never access Dynamics 365 and losing them for a sprint wouldn't affect the dev team's velocity then they are really a delegate for the product owner, and they are not part of the dev team.
You might even have both types of business analysts in your Scrum team.
During sprint planning
Planning poker is most often played during sprint planning when the Scrum team is developing the sprint backlog for the upcoming sprint. During sprint planning, the team will play planning poker on unestimated items at the top of the backlog. Then the product owner finalises the priority of those items before the dev team forecasts which of the high priority items it can complete during the sprint.
If you only play planning poker during sprint planning, and you have a lot unestimated, high-priority items, your game will be rushed as you try to estimate everything within the sprint planning timebox.
During storytime
Planning Poker Via Skype Download
I like to play planning poker during backlog refinement sessions that my team holds several times during each sprint. I usually run short backlog refinement sessions, called storytime, several times a week during each sprint. We try and determine which stories we're going to discuss before the workshop so that the right subject matter experts and developers can attend. If there is enough of the development team available, we'll play a quick planning poker game on the stories we've just discussed.
In my project roadmapping sessions, I advocate for estimating the entire product backlog when the requirements are described using epic user stories. The roadmap provides the Dynamics 365 sponsor and product owner with an overall project cost estimate and timeline.
I don't recommend refining all those epics into smaller, implementable user stories straight away. I'm a big fan of just-in-time analysts and estimation. Refine and estimate stories you might complete in the next sprint or two. This way your estimates are fresh and use everything you've learned recently about deploying Dynamics 365 in this project.
Estimating with a physically co-located team
You can play planning poker with a set of printed planning poker cards [affiliate link] if your team is physically co-located.
If you are colocated in the same room and don't have a set of planning poker cards handy there are dozens of apps available for smartphones, or you can just use the Calculator app to type in your estimate before revealing it to the team by flipping around your phone.
Estimating with a remote team
There are several online planning poker tools that are great if you're a remote team. These include:
PlanningPoker.com which is free for up to five users and its basic features. Paid plans include support for more than 5 users, integration with JIRA, and import from CSV files exported from VSTS, and some other advanced features. I like planningpoker.com and I've used it in several of my projects, usually without paying for it.
Planitpoker.com has most of the features of PlanningPoker.com but it's free for unlimited users.
Scrumpoker.online is a basic, free tool with the source code available on GitHub.
If you are using Visual Studio Team Services, check out ScrumPoker4Devs on the VSTS marketplace.
OK, so let's get into the details. I've spent all this time talking about planning poker without clearly telling you how we play it.
A game of planning poker goes like this. Someone reads out the title of an unestimated story. It's often the product owner or a proxy reading the story, but the scrum master can facilitate the process too. Ideally, the team can read the title, description and acceptance criteria on a shared screen.
The development team can ask questions about the story and clarify their assumptions. It's OK to propose and discuss some design options, but I strongly recommend you don't lock in a particular design until you're about to implement the feature.
Importantly, developers shouldn't be calling out how much effort it'll take or how big or small the story is. The same goes for product owners who sometimes try to coerce the team into underestimating stories in the hope that will somehow improve velocity. It doesn't.
In planning poker, we estimate in private. Using cards, a mobile app or a web app each of the developers privately estimates the complexity of the story. Once everyone has estimated, everyone's estimates are revealed.
Arriving at a consensus estimate
Let's say that everyone estimated a story was 5 story points (I'll explain story points in a moment), except Lachland and Olena. Lachlan thinks it's 1 story point and Olena estimated 13 story points then I'd invite Lachlan and Olena to describe their assumptions. Then we'd all estimate again.
If the divergence was much closer time, let's say Lachlan had voted 3 points and Olena had voted 8 points, during the discussion they might both be willing to settle on 5 story points without a round of re-estimation.
Games go much quicker if you can avoid rounds and rounds of re-estimation, but it's important not to coerce developers with high or low estimates to always compromise and accept the average. Sometimes one person knows about some hidden complexity that everyone else has missed, or has implemented a similar feature before many times using a creative workflow that no one else has thought of.
If this is the first time your Scrum team has played planning poker then you need to establish a couple of things:
Your estimation units and scale
Your baseline story
Your definition of done
Estimation units
What units and scale are your team going to use to estimate their work?
Story points for estimating relative complexity
I like to estimate using relative complexity using story points. What does this mean? Let's break it down. I'll explain story points in a moment. First of all, complexity is a measure of effort plus risk. If I think two stories will take about the same amount of effort, but the second is significantly riskier than the first then I use a higher estimate for the second story.
Planning Poker Via Skype App
For example, let's say we have two stories: one to configure auditing for the account entity, and the second to data export service for the account entity. They probably require approximately the same amount of effort, but the team has less experience with the data export service so there's a risk we hit an issue that needs to be resolved. Same effort; different risk profile. So these two stories might have different estimates.
When I was discussing those two stories, auditing and data export, did you notice I was comparing them? What I'm trying to do is compare the relative complexity of any two stories. A dev team should be able to take any two stories and be able to estimate how complex is this story compared to that story? I prefer to estimate relative complexity.
Story points are just an arbitrary unit of measure. Other than velocity (a measure of how many story points a development team gets done in a sprint), there is no fixed conversion rate from story points into time.
Story points are agreed by your development in a baselining exercise I'll describe in a moment, but the story points used by one Scrum team are not the same as those used by another.
You can't compare developers or teams by measuring how many story points they complete. They are used for forecasting how much work the team can commit to in a sprint, and not as a productivity performance indicator.
Ideal days for absolute effort
Other teams prefer to estimate in absolute effort. Their unit of measure is usually the ideal day. An idea day is a day with good coffee and no interuptions, meetings or other distractions. When estimating a story they ask, how many ideal days' effort would it take to complete this story? I don't like using ideal days because each team member's level of experience and productivity is different so what they can achieve in a day will vary.
Planning Poker Via Skype Software
There's also a cultural issue: an ideal day in the US is 8 hours (or more), most of the rest of the world it's 7 hours or less. In Ireland an ideal day is spent in the pub with a pint of Guinness, not working on Dynamics at all. John Grace developed the North52 developer productivity tools for Dynamics in Ireland because he wanted more ideal days in the pub.
I don't use ideal days, I use story points. In fact, I don't think I've ever used ideal days or any absolute effort estimation scale in any of my Dynamics 365 projects.
Estimation scale
Most Scrum teams use a modified Fibonacci scale when estimating.
In a Fibonacci sequence, the next number is the sum of the previous two numbers so that scale goes 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 and so on. The increasingly large numbers make sense because we're much better at estimating small things accurately than huge things.
But because most of us have trouble working with awkward numbers, the most common Fibonacci scale is 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 and 100. If I'm using a customisable scale, I like to use ½ and 60 too.
When I'm estimating epics, I use the numbers at the upper end of the scale: 20, 40, 60, 100. I recommend splitting large user stories so that your largest user stories are 13 story points or less.
How do you establish a baseline user story?
A baseline story is a story in your backlog that is well-refined and well-understood by everyone in the development team, with minimal risks or unknowns, and could be implemented by the team in a day or two.
I like to assign my baseline story 3 story points.
This baseline story now becomes the story to which the complexity of all other stories is compared.
If the next story is much simpler than the baseline it's two points; if it's nearly twice as complex, it's 5 points. If it's more than twice times as complex, it's 8 points and so on. Really trivial stories that still require some effort are ½ a point. Some teams use 0 point stories for items that require barely any effort at all, but even tracking a 0 point story creates work so I don't use them in my Dynamics projects.
Definition of Done
Another agreement your team needs to have before estimating the backlog is your definition of done. Each item in the backlog should have acceptance criteria that we can use to test the item so that we know it's acceptable to the product owner. Acceptance criteria provide details and we can use these to write more detailed test cases.
The definition of done applies to all product backlog items. They are a superset of acceptance criteria that every item, particularly user stories, have to meet.
Each Scrum team will have a different definition of done. If you have multiple Scrum teams working on the same product, then you should have a shared definition of done for all the teams.
An example definition of done for Dynamics 365 stories
Your definition of done could include:
The solution components all have the item ID# and a description.
The item has been peer-reviewed
The item has been tested in the QA instance
The item has been tested in the SIT instance
The item has been documented in the Dynamics 365 system wiki
A change manager has written release notes for the item
Your baseline, simple 3 point story has to meet its own acceptance criteria and meet the definition of done.
Over time Scrum teams change their definition of done, usually by adding new criteria that improve the quality of their Dynamics 365 product increment. When your team does this, I leave your baseline story at 3 story points no matter what changes you've made to your definition of done. Your average velocity might dip a little because there is extra work to do to release the similar features as before, but that's not a big deal unless you're using velocity as a KPI -- which is not something that I'd ever recommend anyway.
So that's it for planning poker, the consensus-drive team game for estimating Dynamics 365 stories.
We've covered the benefits of planning poker and why a consensus-driven gamified approach to estimation is a good idea. We've discuss when we play during a typical sprint and who is involved. I gave you some ideas for using planning poker cards or apps, and described the mechanics of the game itself. Finally, we looked at the things you need to establish before you play: your estimation units and scale, your baseline story and your definition of done.