Is your team ready for planning poker? How have you helped team members embrace the differences in each other to be safe about using it? Leave me your thoughts below!
At my last job, when playing planning poker, the dev lead would always put down a number that was about 1/3 of everyone's estimate. This made some people think he was some kind of programming god. But, in reality, he and others would NEVER put any stock into unexpected events. Oh, and we RARELY had HALF of the requirements. I don't know how many times I heard someone say to me: "I know we don't know what the user wants, but just give me a number. It's just something to start with. It can easily be changed once we figure out what the requirements are." I fell for that trap many times. And, just like a trap, I walked into it, sprung the trap, and got whacked by the trap. I've been out of a job, due to the beer virus, but I hated my last job. I honestly wished I would have chosen a different path. I have a speech impediment, and I enjoyed programming at an early age. However, the speech impediment makes interviews, and communication hard to navigate and may give people the wrong impression. If I leave the profession, I have to admit that it supported me for 16 years, and it was financially good to me. But, I've run into the wrong companies, or I just suck...well I've had architects, seniors, and leads tell me I'm very good at solving problems. However, it is a sad day for me, as I was the only sibling to lose their job due to the beer virus, and none of my wife's 5 siblings had any ill effects. Her family keeps asking why I don't have a job yet. It's emasculating. But, I don't want to go back...to many ass holes, red tape, layoffs (3 in a row), and bad blood for me to easily recover. My neighbor across the street tried to come over and cheer me up, but instead bothered the shit out of me when he said "I'm sorry, but I don't have any idea what you're going through. I worked for AT&T for 45 years without interruption, and have a nice pension". Hey, I hope things are good with your career and family. You seem like the coolest guy. Thanks for your videos.
Hey there thanks for the courage to be vulnerable and share what you're going through. That sounds incredibly hard man. It's tough to know what to put up with. While it's important to provide for our families - I believe they don't want us to keel over from stress. I hope you find the right path for you - whether that means a different mindset with development, or something new!
Thanks Jayme for another great content, This reminds me of my first company, I was a system & business analyst back then, and this was the estimation technique used by my team and my mentor on the company. I never had the chance to research its name, and just learned the name from you. 1 thing I've experienced with planning poker, which you have said, an advantage of "Reduced padding" was that it wasn't really effective on my team back then. What the developers on my team did (as a workaround) was to "re-distribute the padding" and WE, and the other non-programmer in the room had no idea. It goes like this. The modules were broken down to a specific feature/function. eq. -Add members -Remove members -Update members -Delete members and so on.. We were doing planning poker for more than 5 projects already. but the estimates for these small items we're not changing. -Add members = 3 hours -Remove members = 3 hours -Update members = 3 hours -Delete members = 3 hours Module by module and project by project it remains the same. But in reality, the programmer's development speed and familiarity to the feature are improving. from the first project / module, it may be true that it will take around 3 hours to do that function, however after a while, there's re-usability, and in reality may only take. 15 minutes. so instead on bulking up padding on 1 feature, the developers just re-distributes it and they were able to slack.
Caesar Rodman interesting, so if I understand right developers were spreading buffer time across all of the tasks so they could slack off? Or do you just mean having “slack” in the estimates to account for unknowns?
"They're spreading the buffer time across all of the tasks so they could slack off." -- this one. and since there are non-programmers in the room, we had no idea, that they could re-use.
I think the reason it's called "poker" is related to the fact that if you make a bold claim that something is simpler than it looks, you are committing to do it yourself. Even if you are a manager.
I think the reason it's called poker is because (a) cards are used that are the same size as playing cards (b) there is an alliteration (words that start with the same sound) that sounds pleasing to the ear.
In our team the voters are the same persons who would actually be doing the tasks. So, test engineers vote for their tasks, and developers vote for their tasks. And the voters know that they will be the ones who will actually be doing the tasks with the estimates they gave. We always take the median value, i.e. from values, 5, 8 and 13, value 8 would win. This eliminates the most pessimistic and the most optimistic vote, and so the most realistic value gets chosen. On top of that, some 10-20% risk buffer is added, as it’s no surprise that there will always be some surprises in a project. Now, if a manger or some other ”outsider”, who won’t be implementing the tasks, gets to vote, the poker game becomes unrealistic really fast…
Story points were just supposed to be a way to help developers get an idea of the relative size of things to prioritize what to work on. They were never meant to equate to real effort and then put into a sprint schedule. It's a dysfunction of bad agile/scrum implementations.
@@HealthyDev what is the VALUE to the customer of spending 2 hours to do the estimation of story point then just spending those 2 hours focusing on delieving release faster to the customer ?
I am on a cross functional team, how would planning work for this? There are backlog items that i simply cannot or will not do. And there are items that nobody can do but me. The problem comes from when I say oh, Migrating 27 legacy apps, thats an 8 or 13 (Fibonacci scale), and the network guy, our DBA, or Server admin, says, you just have to copy them to the server, its a 2... Then our scrum master is saying we need to meet in the middle, or I need to take 15-20 minutes out of this meeting to explain what all is involved, the unknowns (Ie, do we even have the source code). In my particular case I ended up caving since I did not have the ability at the time to explain all the pitfalls due to inexperience working with these legacy apps, and i ended up with a very lopsided estimate because it ended up taking almost a month to get everything ironed out. And on the flip side, One of the items is creating a new database server for these legacy applications, I dont have the permissions, I dont have the knowledge. The learning curve alone could be split up into multiple PBI's. I'm no DBA, How do i size this? I don't even feel like i have the right to do so, And in return I feel like telling the guy undersizing my PBI's "Well if it's only a 2 for you, you can take that one" (Or is my assumption that cross functional teams with widely different skill sets should not be doing this at all correct?)
Hey Josh, let's see if I can unpack this one. Quite a bit here. Might need some back and forth to give you any meaningful advice. The first thing I'll throw out there, and this is just my experience, is that a cross functional team (where you've got devs, UX, and ops sharing a backlog) only makes sense when the work in that backlog is in support of ongoing development of a single product. Whenever there's a major cost-cutting initiative, or a cross-product initiative such as migrating a slew of products to different infrastructure, it gets a little grey whether that belongs in a separate work stream or not. With that being said, you mention your hesitance to give estimates for some of your work because of your unfamiliarity with some of the tasks you're being asked to do. What I've done in this situation sometimes, and I'm not sure if it will help or not, is to pick a boxed set of time (say, a certain number of hours etc.) to investigate the task more fully to even come up with an estimate. Some agile practitioners call this a "research spike" and its basically a user story where it might say something like "As an IT administrator, I need to evaluate the scope of migrating 27 legacy applications so I can estimate the effort needed". Now that might be overkill to put it in a user story, but if you've got a team that's really anal about doing agile/scrum to the letter that will get you through. The short of it is, if you don't feel comfortable estimating something, push for getting a research spike to get a better estimate. Help the business understand that you're doing this because you're going to have to spend time figuring it out anyway, and if they want any semblance of predictability or understanding the cost, you're doing this to help them. As for your last point, I absolutely think it's fine to hand a product backlog item over to another person who's more confident with it if they disagree with your estimate. I never take on tasks that have been estimated by someone else. And if someone hands me work that's already been estimated ahead of time, I always tell the business that those estimates were for that person, and every engineer accomplishes tasks at different rates. They are happy to track the project to the original estimates, but they WILL be wrong since I need to estimate for my own skill - which may make them go faster, or slower. I hope some of that helps.
One more thing I should have added, and I mention this in one of my estimation videos, is that I'd recommend you make very clear that a research spike isn't a guarantee that you'll be able to estimate the work at the end of that fixed box of time. Let's say you say "I'm going to spend no more than 2 days before coming back to you with what I've learned". At the end of that 2 days, you may actually need MORE time to figure out an estimate because you're more informed about the scope of the work. It's really important to bring this up ahead of time so they aren't surprised by it. Your mileage may vary...
First of all, Thank you for your answer, It does give me a bit more confidence in how i need to resolve these issues. I should have called for the research spike not so much for myself, but to educate the other members of the team on all the pitfalls of what we were trying to do. (I was too inexperienced at the time to do it, but it's great info for the future) As far as telling the other guy to take on the PBI, it would be more of a passive aggressive joke, as he could not accomplish the task without a significant learning curve or without basically standing beside me as I did all the work.
One thing on using this research spike, the scrum master states that everyone on the team needs to take a PBI, should this research spike be added to the backlog?
Yes. It’s a PBI with an estimate, it’s just important that people know you’ll “come up for air” before or at when the estimated time has elapsed to decide whether more research time is needed, or if you have enough information to now scope the actual work.
I disagree with a couple of your reasons for not using planning poker, but it may be that you and I are thinking about using it at different times in the process. Based on the video, I think you're expecting it to be used just before each sprint when the team knows who will be doing the work. I've used it to help prioritize backlogs and to get a general idea of relative effort of different backlog items well before we knew who would work on an item. In the case of using planning poker before it's know who will work on the task, I'd argue that it actually reduces competence bias. When one top programmer sets the estimates for everyone without input, there's much more likely to be competence bias. Also, as long as the team has open, substantive discussions, the person with the competence bias may have some excellent information to share with the team about how to reduce the estimate. They may say, "We have a module that already does that, and you can call it," or something of the sort. I agree that if the team is judgmental and doesn't create a safe space for open discussion, planning poker is pointless. However, I'd say that pretty much all agile techniques (and other techniques) are heavily damaged when a team can't be open with their ideas. I think that planning poker is a great tool, but like any tool, it depends on how people are using it.
I can’t disagree there. I tried to make it clear in the video that I’m not trying to tell people not to use it, but to be aware of some of the cultural reasons I’ve seen where it doesn’t make sense. I’m of the opinion that work should always be prioritized based on economic impact and not effort - but that’s another video I haven’t made yet! Always appreciate your insights.
I look forward to that video. I like the idea of using economic impact. I would assume that effort would be an input into economic impact, so effort would still be relevant to the equation. By the way, have you used a tool called a decision tree? I learned about them as part of a class at UT, and it seemed like a great way to organize economic impact unknowns and make decisions about what a company should invest in.
Why would we use such an ill-defined measurement as "points"? What is a point a measure of exactly? If we just used days as a measurement, we could normalize it by defining it as the number of days it would take for a senior to complete.
Points were invented by Ron Jeffries. He was one of the original authors of the agile manifesto. Waterfall was popular at the time, and it used units of time like hours to estimate. Projects were consistently late. Software development was determined too unpredictable to estimate. Points were created as a way for developers to guess (estimation is guesswork in software) the relative size of two or more possible things to work on next. They were to be used by the development team only to try to always pick small things to work on. This is so the team would complete work more often to get it in the hands of customers. Then other people who didn’t understand their purpose began using them as commitments to the business, which is what hours were used in waterfall for - the exact opposite of Ron Jeffries’ intention. He has since posted on X that he regrets ever creating story points, since they are now just used as mini waterfall commitments within a two week sprint in many scrum processes. I hope that helps a bit.
One important think "Planning Poker" forgets is that what for guy A is a 5 for Guy B is a 8, while for Guy C is a 13. Who's right then? None of them, is Guy G, the one actually doing the task. The problem with planning poker is the same with democracy, everyone votes, but maybe a few of them took enough time to investigate and none of them is doing the actual work, except the guy who took the responsibility constrained by the estimations made by others.
Is your team ready for planning poker? How have you helped team members embrace the differences in each other to be safe about using it? Leave me your thoughts below!
At my last job, when playing planning poker, the dev lead would always put down a number that was about 1/3 of everyone's estimate. This made some people think he was some kind of programming god. But, in reality, he and others would NEVER put any stock into unexpected events. Oh, and we RARELY had HALF of the requirements. I don't know how many times I heard someone say to me: "I know we don't know what the user wants, but just give me a number. It's just something to start with. It can easily be changed once we figure out what the requirements are." I fell for that trap many times. And, just like a trap, I walked into it, sprung the trap, and got whacked by the trap. I've been out of a job, due to the beer virus, but I hated my last job. I honestly wished I would have chosen a different path. I have a speech impediment, and I enjoyed programming at an early age. However, the speech impediment makes interviews, and communication hard to navigate and may give people the wrong impression. If I leave the profession, I have to admit that it supported me for 16 years, and it was financially good to me. But, I've run into the wrong companies, or I just suck...well I've had architects, seniors, and leads tell me I'm very good at solving problems. However, it is a sad day for me, as I was the only sibling to lose their job due to the beer virus, and none of my wife's 5 siblings had any ill effects. Her family keeps asking why I don't have a job yet. It's emasculating. But, I don't want to go back...to many ass holes, red tape, layoffs (3 in a row), and bad blood for me to easily recover. My neighbor across the street tried to come over and cheer me up, but instead bothered the shit out of me when he said "I'm sorry, but I don't have any idea what you're going through. I worked for AT&T for 45 years without interruption, and have a nice pension". Hey, I hope things are good with your career and family. You seem like the coolest guy. Thanks for your videos.
Hey there thanks for the courage to be vulnerable and share what you're going through. That sounds incredibly hard man. It's tough to know what to put up with. While it's important to provide for our families - I believe they don't want us to keel over from stress. I hope you find the right path for you - whether that means a different mindset with development, or something new!
Thanks Jayme for another great content,
This reminds me of my first company,
I was a system & business analyst back then, and this was the estimation technique used by my team and my mentor on the company.
I never had the chance to research its name, and just learned the name from you.
1 thing I've experienced with planning poker,
which you have said, an advantage of "Reduced padding" was that it wasn't really effective on my team back then.
What the developers on my team did (as a workaround) was to "re-distribute the padding"
and WE, and the other non-programmer in the room had no idea.
It goes like this.
The modules were broken down to a specific feature/function.
eq.
-Add members
-Remove members
-Update members
-Delete members
and so on..
We were doing planning poker for more than 5 projects already.
but the estimates for these small items we're not changing.
-Add members = 3 hours
-Remove members = 3 hours
-Update members = 3 hours
-Delete members = 3 hours
Module by module and project by project it remains the same.
But in reality, the programmer's development speed and familiarity to the feature are improving.
from the first project / module, it may be true that it will take around 3 hours to do that function, however after a while, there's re-usability, and in reality may only take. 15 minutes.
so instead on bulking up padding on 1 feature, the developers just re-distributes it and they were able to slack.
Caesar Rodman interesting, so if I understand right developers were spreading buffer time across all of the tasks so they could slack off? Or do you just mean having “slack” in the estimates to account for unknowns?
"They're spreading the buffer time across all of the tasks so they could slack off." -- this one.
and since there are non-programmers in the room, we had no idea, that they could re-use.
I think the reason it's called "poker" is related to the fact that if you make a bold claim that something is simpler than it looks, you are committing to do it yourself. Even if you are a manager.
I think the reason it's called poker is because (a) cards are used that are the same size as playing cards (b) there is an alliteration (words that start with the same sound) that sounds pleasing to the ear.
In our team the voters are the same persons who would actually be doing the tasks. So, test engineers vote for their tasks, and developers vote for their tasks. And the voters know that they will be the ones who will actually be doing the tasks with the estimates they gave.
We always take the median value, i.e. from values, 5, 8 and 13, value 8 would win. This eliminates the most pessimistic and the most optimistic vote, and so the most realistic value gets chosen. On top of that, some 10-20% risk buffer is added, as it’s no surprise that there will always be some surprises in a project.
Now, if a manger or some other ”outsider”, who won’t be implementing the tasks, gets to vote, the poker game becomes unrealistic really fast…
why we are using the infinite / conceptual story points fitting or mapping into a finite / fixed 2 weeks sprint cycles ?
Story points were just supposed to be a way to help developers get an idea of the relative size of things to prioritize what to work on. They were never meant to equate to real effort and then put into a sprint schedule. It's a dysfunction of bad agile/scrum implementations.
@@HealthyDev what is the VALUE to the customer of spending 2 hours to do the estimation of story point then just spending those 2 hours focusing on delieving release faster to the customer ?
Perhaps Event Stormimg can be used as a prerequisite to Poker Planning.
Scott Nimrod cool stuff! I’m a long time advocate of DDD and have participated in Gamestorming - but never together.
Cool idea.
I am on a cross functional team, how would planning work for this? There are backlog items that i simply cannot or will not do. And there are items that nobody can do but me. The problem comes from when I say oh, Migrating 27 legacy apps, thats an 8 or 13 (Fibonacci scale), and the network guy, our DBA, or Server admin, says, you just have to copy them to the server, its a 2... Then our scrum master is saying we need to meet in the middle, or I need to take 15-20 minutes out of this meeting to explain what all is involved, the unknowns (Ie, do we even have the source code). In my particular case I ended up caving since I did not have the ability at the time to explain all the pitfalls due to inexperience working with these legacy apps, and i ended up with a very lopsided estimate because it ended up taking almost a month to get everything ironed out. And on the flip side, One of the items is creating a new database server for these legacy applications, I dont have the permissions, I dont have the knowledge. The learning curve alone could be split up into multiple PBI's. I'm no DBA, How do i size this? I don't even feel like i have the right to do so, And in return I feel like telling the guy undersizing my PBI's "Well if it's only a 2 for you, you can take that one" (Or is my assumption that cross functional teams with widely different skill sets should not be doing this at all correct?)
Hey Josh, let's see if I can unpack this one. Quite a bit here. Might need some back and forth to give you any meaningful advice.
The first thing I'll throw out there, and this is just my experience, is that a cross functional team (where you've got devs, UX, and ops sharing a backlog) only makes sense when the work in that backlog is in support of ongoing development of a single product.
Whenever there's a major cost-cutting initiative, or a cross-product initiative such as migrating a slew of products to different infrastructure, it gets a little grey whether that belongs in a separate work stream or not.
With that being said, you mention your hesitance to give estimates for some of your work because of your unfamiliarity with some of the tasks you're being asked to do. What I've done in this situation sometimes, and I'm not sure if it will help or not, is to pick a boxed set of time (say, a certain number of hours etc.) to investigate the task more fully to even come up with an estimate.
Some agile practitioners call this a "research spike" and its basically a user story where it might say something like "As an IT administrator, I need to evaluate the scope of migrating 27 legacy applications so I can estimate the effort needed". Now that might be overkill to put it in a user story, but if you've got a team that's really anal about doing agile/scrum to the letter that will get you through.
The short of it is, if you don't feel comfortable estimating something, push for getting a research spike to get a better estimate. Help the business understand that you're doing this because you're going to have to spend time figuring it out anyway, and if they want any semblance of predictability or understanding the cost, you're doing this to help them.
As for your last point, I absolutely think it's fine to hand a product backlog item over to another person who's more confident with it if they disagree with your estimate. I never take on tasks that have been estimated by someone else. And if someone hands me work that's already been estimated ahead of time, I always tell the business that those estimates were for that person, and every engineer accomplishes tasks at different rates. They are happy to track the project to the original estimates, but they WILL be wrong since I need to estimate for my own skill - which may make them go faster, or slower.
I hope some of that helps.
One more thing I should have added, and I mention this in one of my estimation videos, is that I'd recommend you make very clear that a research spike isn't a guarantee that you'll be able to estimate the work at the end of that fixed box of time. Let's say you say "I'm going to spend no more than 2 days before coming back to you with what I've learned". At the end of that 2 days, you may actually need MORE time to figure out an estimate because you're more informed about the scope of the work. It's really important to bring this up ahead of time so they aren't surprised by it. Your mileage may vary...
First of all, Thank you for your answer, It does give me a bit more confidence in how i need to resolve these issues. I should have called for the research spike not so much for myself, but to educate the other members of the team on all the pitfalls of what we were trying to do. (I was too inexperienced at the time to do it, but it's great info for the future) As far as telling the other guy to take on the PBI, it would be more of a passive aggressive joke, as he could not accomplish the task without a significant learning curve or without basically standing beside me as I did all the work.
One thing on using this research spike, the scrum master states that everyone on the team needs to take a PBI, should this research spike be added to the backlog?
Yes. It’s a PBI with an estimate, it’s just important that people know you’ll “come up for air” before or at when the estimated time has elapsed to decide whether more research time is needed, or if you have enough information to now scope the actual work.
I disagree with a couple of your reasons for not using planning poker, but it may be that you and I are thinking about using it at different times in the process.
Based on the video, I think you're expecting it to be used just before each sprint when the team knows who will be doing the work. I've used it to help prioritize backlogs and to get a general idea of relative effort of different backlog items well before we knew who would work on an item.
In the case of using planning poker before it's know who will work on the task, I'd argue that it actually reduces competence bias. When one top programmer sets the estimates for everyone without input, there's much more likely to be competence bias. Also, as long as the team has open, substantive discussions, the person with the competence bias may have some excellent information to share with the team about how to reduce the estimate. They may say, "We have a module that already does that, and you can call it," or something of the sort.
I agree that if the team is judgmental and doesn't create a safe space for open discussion, planning poker is pointless. However, I'd say that pretty much all agile techniques (and other techniques) are heavily damaged when a team can't be open with their ideas. I think that planning poker is a great tool, but like any tool, it depends on how people are using it.
I can’t disagree there. I tried to make it clear in the video that I’m not trying to tell people not to use it, but to be aware of some of the cultural reasons I’ve seen where it doesn’t make sense.
I’m of the opinion that work should always be prioritized based on economic impact and not effort - but that’s another video I haven’t made yet!
Always appreciate your insights.
I look forward to that video. I like the idea of using economic impact. I would assume that effort would be an input into economic impact, so effort would still be relevant to the equation.
By the way, have you used a tool called a decision tree? I learned about them as part of a class at UT, and it seemed like a great way to organize economic impact unknowns and make decisions about what a company should invest in.
Why would we use such an ill-defined measurement as "points"? What is a point a measure of exactly? If we just used days as a measurement, we could normalize it by defining it as the number of days it would take for a senior to complete.
Points were invented by Ron Jeffries. He was one of the original authors of the agile manifesto.
Waterfall was popular at the time, and it used units of time like hours to estimate. Projects were consistently late. Software development was determined too unpredictable to estimate.
Points were created as a way for developers to guess (estimation is guesswork in software) the relative size of two or more possible things to work on next. They were to be used by the development team only to try to always pick small things to work on. This is so the team would complete work more often to get it in the hands of customers.
Then other people who didn’t understand their purpose began using them as commitments to the business, which is what hours were used in waterfall for - the exact opposite of Ron Jeffries’ intention.
He has since posted on X that he regrets ever creating story points, since they are now just used as mini waterfall commitments within a two week sprint in many scrum processes.
I hope that helps a bit.
I'm for the idea and think it's good. But because some individuals on my team is giving me impostor syndrome I would rather not do it
One important think "Planning Poker" forgets is that what for guy A is a 5 for Guy B is a 8, while for Guy C is a 13. Who's right then? None of them, is Guy G, the one actually doing the task.
The problem with planning poker is the same with democracy, everyone votes, but maybe a few of them took enough time to investigate and none of them is doing the actual work, except the guy who took the responsibility constrained by the estimations made by others.
This is 100% accruate.
We all know it's really #3.