Have you ever started implementing a software feature from a specification that seemed to be complete, only to find that almost every time you asked a question you uncovered another business requirement?
Hi John –
I’m working on the ‘Approve’ button and just want to confirm the location: it should appear at the bottom right, below the Terms and Conditions, right?
Hi Hanaa –
Yes, that’s the right place, but it should only be there if the client’s previous payments are up to date.
So, you’re not quite done.
Hi John –
Would you let me know if this is correct?
Client payments are up to date if:
1. This is a new client, or
2. All bills have been paid within the 90 day grace period
3. Ignore unpaid bills if they fall within the last 90 days
Looks like we’ve figured out the rules for determining if client payments are up to date – so we know when to hide the button. Or should it just be disabled? Or do we need to show a message?
Anyway, it doesn’t seem like much more work.
Hi Hanaa –
Yes, that’s right, but we also check if the client’s account is current (i.e. not on hold). If it’s January, we have to check their year-end reports to determine their status. How hard would it be to have another button on this screen to let us view the report?
Including Jay: Jay, is there anything else we need to consider about the ‘Approve’ button?
Oh. Is the client’s account on hold? Can we view a report? And the dreaded “how hard would it be…?”
And now someone else is involved in the email trail.
Hi John and Jay –
Maybe we should meet.
You really thought you’d finish today, didn’t you?
Why do we have surprises?
Even though we spend time gathering requirements and creating mock-ups at the beginning of a project, we can miss things that could have come out by asking a few more questions. It’s hard to make reasonable estimates with incomplete information.
Planning poker helps us to get to the important questions.
What is Planning Poker?
Isn’t it just another way to estimate how much time it will take to implement a feature?
Actually, the estimates are secondary.
The biggest benefits are the engagement of the final users of the system and the resulting quality of the requirements.
Planning poker is an agile method used to get consensus on what work is to be done and to get an idea of the relative size of each task.
Business experts are involved. We also include testers, developers, architects, and project managers.
How does it work?
The product owner presents the product backlog, which is the list of all features that are to become part of the software. It is usually sorted with the highest priority items at the top.
With a set of planning poker cards and someone to record the results, we’re ready to go.
In a planning poker session, we go through the items in the backlog one by one until we agree that we have enough work to do for the next iteration. The backlog items are often in the form of user stories.
Every person around the table has a deck of planning poker cards. The numbers on the cards usually range from 0 to 100, with values that are close to the Fibonacci sequence.
To begin, a single story is presented and the group discusses it until the participants feel they have enough information to make an estimate.
Each person selects a planning poker card representing how big they think the task is, but doesn’t show it until everyone is ready. The idea behind waiting for everyone to decide is that we don’t want to influence another person’s estimate.
What’s the big deal?
If everyone agrees on how big the task is (or close to it), there’s likely a good understanding of what’s involved in this feature.
If there are some bigger differences, that’s where the strength of planning poker really comes in. The people whose estimates were smallest and largest usually begin by explaining the assumptions they’ve made to come to their estimates.
This discussion sometimes gets technical – maybe a discussion about a system limitation, or on the flip side, someone already knows how to implement the feature – they’ve done it before.
What’s really interesting is that the product owner almost always becomes engaged in discussing their expectations. Are there some things that they assumed, since they know the business side of the process in much more depth than the development team? As designers and developers, we’re getting to hear a lot more detail up front than we might otherwise.
This is also where product owners get to see that we want to create functionality that will ultimately make their job easier. By describing the details of what they do, they’re telling us that nothing is as simple as it seems on the surface. They’re explaining in detail what they know and what kinds of decisions they have to make every day.
As we go through the process of determining the relative size of each feature, the product owner’s priorities may change. If one feature is going to take 10 times as long as another to complete, it may move down in the list.
More people asking and answering more questions face to face means deeper and better understanding of requirements.
The end result of this agile technique is that the client has more information to make decisions about which features are most valuable, and the development team is going into design and implementation with a better understanding of their goal.