The idea of using story points instead of time estimations is to estimate complexity instead of time, because time estimations are usually bad. Having non-linear estimation values for planning poker (or any form of estimation) honestly makes a lot of sense - there is no way when you estimate something in say hours that you could say it's 1023 instead 1024 hours, so taking away the granularity in the first place is useful. Also prevents PMs from haggling... Maybe. However the only rules for planning poker (imo) are that your estimation is made secretly, revealed together and openly discussed. I'm not sure I'm for or against the PO or PM taking part - I think it's a waste of their time, but I also think it can help them gain an understanding of the complexity of tasks.
@watcheths the PO can state his opinion or ask questions, but shouldn't be voting. POs voting or otherwise force decisions are a big red flag indicating that at least part of the company isn't doing scrum properly. The PO is in charge of the backlog, but already doesn't have a say on how much a team will do in a sprint. That's based on team velocity or its estimate if the team is new. If the PO tries to push the dev team or tries to tweak the numbers that's bad. Ideally the scrum master should spot this and fix/escalate the issue, but if the company is dysfunctional, chances are the scrum master is just another manager that doesn't understand how scrum works and thinks he's in charge too.
@watcheths what I obviously mean is that POs shouldn't give their estimate, or worse force their estimate as the final one. I don't know why I went with "vote", I never voted for estimates
It's pretty much exclusively in place so the people who are ordering a team to create a product can check in and see if it feasibly can make a deadline. It's fine so long as those meetings are separated from the devs outside of evaluating the points per story (so it avoids the chance of extreme over/underestimates), lots of companies however will have everyone participate in these which wastes lots of time and money. Plus people aren't fortune tellers usually so these estimates aren't always accurate and oftentimes cause frustration at some point (like if a simple bug fix reveals other issues which causes a spike in stories)
Dude, not everything is black and white; For some projects the problem is that coders know nothing about what features is valuable to a customer and project managers know nothing how an actual programming task might take. Now, you don't have the have an hour long fkin speech about story points and have Janet from accounting join.
To me it sounds like taking something that should be done quickly and conversationally between the people working on a project, and making it an official management task. Not necessarily extra steps as it probably should be done, but definitely ballooning a 5 min discussion between knowledgeable workers into time-wasting nonsense to justify middle-management's existence.
It's just trying to get everyone on the same page and timelines. By assigning tangible quantities to tasks for which the difficulty is subjective, it lets others get a gauge for how you view a task
Thing is, devs usually think that timelines and tasks are magically created by God. You need someone to create the timeline of your project and keep lazy devs in check. He usually focuses on making bad practices seem like its what happens all the time, which isnt the case in the real world.
I find planning poker useful as long as it's only Devs / QA. Yet to meet a product manager / BSA who doesn't think every story is a maximum of 3 points.
This is how it works at my company. The PO is effectively asking just the devs how long it might take. It's fine if doing the estimations actually helps in some way such as an environment where deadlines are critical, but otherwise, it can be near useless. My current team got a new PO and lead who wanted to try estimations. Us devs said it wouldn't work for the type of work we do. 6 months later, we're not estimating things anymore (again).
> Yet to meet a product manager / BSA who doesn't think every story is a maximum of 3 points. Not sure I've understood you correctly, but there is an assumption that the SP estimate has a limit not because of someone's will, but because SP is a metric of complexity of the task, so if it's complexity is way too high - it's shoud be considered to be decomposed to smaller manageble tasks. Obvious cap value is how much SP delivers an average developer in your team. I.e you have task estimated 8 sp and avg delivery is 5 sp per dev in your team. So there is a super-high chance that this task cannot be done (and thus show progress to PO) within the sprint duration. So the task should be split. Final numbers depends on team and their estimate habits
I thought planning poker was going to be “devs bid on the estimate for the task and the lowest person gets the task, and people only get paid per complete task.” Evil, or brilliant. I let you decide.
3 vs 5 is why I favored powers of 2. The Fibonacci sequence gives an illusion of precision. I got out of agile consulting when I realized that instead of being used to empower developers, and improve communication between devs and the business, it was being used as a tool to micromanage developers and "put them in their place."
That is the only thing such tools would ever be used for, any and all metrics designed is often counter productive. It’s treated often too much like a time “budget” like, if Coworker A and only Coworker A can do Task 1 in 2 hours, does this metric become the hardline to how long the task Sh/Would Take? Despite on Average the task taking twice as long in accordance to set backs/issues/troubleshooting? Once people make the minimum time of any one point/moment as the norm, they want to minimize the time expense like it’s a simple cookie cut thing or done by a push of a button.
@@RurouniHiro One problem with agile is that it's insanely easy to get wrong. The second problem with agile is that it's built on trust, which makes it insanely fragile. The third problem is that improperly used it is slightly more productive than waterfall.
Especially HR. A PM can usually be brought down to earth if the team leans on him well enough. HR thinks they run the place. In all of the companies I've seen, I've never had an even remotely helpful HR, on the contrary. Honestly, not only do they try to order you around, they have a habit of inventing "laws" that support that notion and are always outraged, when you point out that it's bullshit.
@@daulosh Formalities, like signing a new contract or submiting delegation costs are usually handled by them. They often act as if you're making them handle it just for your amusement.
@@Fossil_Frank sounds like it's an issue with your company than HR. Neither of those should be discussed directly by HR with the employee, but rather discussed between the manager and you with HR just preparing the documents and ironing out details relating to legality and company compensation policies.
@@daulosh That's exactly what happens, it's why I said "formalities". It's still a pain to interact with them every single time. Though it's true that this particular company treats the head of HR as more important than not only my boss, but also the regional director for some reason - I was pretty surprised that my last raise was "blocked" by her (apparently all seniors had the same issue, she thinks we're already too well paid). When we threatened to hand in resignations, she sent us mail claiming there are now "laws" that say we can't quit. All that did was give us a good laugh, but this is standard practice for HR in all the companies I've come to know - they practise the asspull whenever something doesn't go their way, never believe a word they say. Anyway, after facing the prospect of having to replace 20+ seniors ASAP, or the company gets fined for missed deadlines, she gave up.
That was what I was thinking. What kind of company has a PM vote on story complexity? We have QA vote because sometimes dev effort is inconsequential but comprehensive testing is a nightmare but for most stories those are less and that is fine, we just ignore them and take the greater effort.
Yeah at every company I was at only devs vote and storypoints were there to protect you from micromanaging stakeholders that overstep boundaries in case a story/feature takes longer than expected.
In this day and age being lazy and hands off pays more money while being hands on and actually learning what it takes for things to actually get done just makes you poor or fired real fast
@@zpa89I feel like dev and QA should each assign their own independent score to each issue. Management sees the combined score, but each department only cares about their own. That way everyone can plan accordingly.
Don't you see he's just playing a role. If you look carefully, everything, I mean EVERYTHING he says is wrong. This is just attention farming. Role being an "overly ignorant self-siloed employee in a software company with broken processes". Sad that some folks in the comments believe him.
The idea is the dev that votes 8 vs everyone else's 3 has thought of a use case that is complex that the project manager never considered. They then explain the real problem and task and it can change the whole project. I have seen it happen. "Oh,He'll I didn't thinknof that"
it's really not, the guy is just overreacting. Usually people who doesn't code should not vote in planning poker, only people who might actually get this task in work
This guy likes to complain a lot. His entire channel is based on making everything and everyone other than devs look stupid. The simple fix to this problem is to only let the devs/people with coding experience vote, which is what actually happens most of the time.
I've only worked at one team that used planning poker, and the only people voting were devs It wasn't completely useless, as it did help learning and understanding of the tasks For example, few people say 8+, one says 3, asking him why, he says because he did a very similar thing in the past and.found a good library to handle the hardest part. Now we know about the library and who best to assign this to for efficiency
@@I-do-not-exist-here the whole idea was to decouple it from a time commitment. Shit hits the fan because PMs want to couple it back to time estimates. The idea behind story points was meant to be an effort/complexity estimate. Most timeline estimates fail anyway, so rather than burden the team's mind with a "time frame", you give it points based on a complexity scale of the team's capability. The team's velocity then becomes a measure of their ability to deliver complexity. If a stable velocity is suddenly slowed down, then its a signal in the team something is happening and get to address it. Done properly, its actually great. Done properly, all these metrics don't leave the dev team. Which we all know doesn't happen much in reality.
@@darylphuah what playbook did you pull this nonsense from? If your time estimates keep being inaccurate just revaluate your teams ability to make estimates.
@@I-do-not-exist-here if you work with anything remotely complex and not just basic CRUD web apps, time estimates ALWAYS run. Either that or the team is padding it so much they can take 2nd jobs. Time estimates get coupled with deadlines very easily. If time estimates are so easy to get right, why did the industry create another way to estimate tasks? The problem is people used the new solution and shoehorned it into the old way of doing things.
@@darylphuah so estimating time never works, so they invented a new system that estimates “velocity” instead? Glad i never got into coding because i would probably shoot myself if my manager ever told me to use the term “story points.”
yeah that's how it's supposed to be done. only people who CAN do the job in the story can vote. can't imagine non devs voting on dev stories. like i wont be voting on design stories.
yep and thing is, this youtuber always makes it sound like the worst possible system in the world. But in the end there has to be some system to manage your product backlog and decide what piece of work to prioritise. Ye agile isn't perfect but it works pretty well if implemented correctly
I know everybody is hating storypoints here, but the logic of this approach is rather clever: - If everybody votes the same, everything is clear and you move to next issue. - If somebody votes differently, it means that person understands less or more of the topic than others. Let's say that for a user story, you need to adjust database, create endpoints and some frontend elements. Almost everybody thinks only about the api and frontend, but there is a person who thinks about the DB and and gives more points because of that. With this approach you actually save time discussing things that are clear and straightforward for everybody and discuss only things where there is some disagreement. Much faster than regular group grooming.
Quantifying subjective complexity only provides a false sense of security, making it seem like all steps are under control. Quantifying subjective complexity is logically equivalent to quantifying subjective estimated time, so there's no need for the extra step. The last benefit you mentioned can also be achieved through 'estimated time.'
Numbers don't matter much. Thus, you can choose to count in body hairs if you want. Plan it poker is just one of the ways to create in depth conversation about certain topic with a guides and not much straying away. It's simple as that. But I agree, we butcher the original idea and even make a business out of it. Which is why it gotten to the point of almost being worthless.
@@gynowhere the problem with estimated time is that it is misleading. Programmers think about the uninterrupted time it will take to write the code. But usually don't include testing, reworks, deploy etc. So when they estimate 10h it takes them week. Usually this ratio is rather consistent, so you can expect the programmer to "do 10h of work" per week. But that sounds bad when he is paid for 40h, so we just call the "10" story points.
I always thought of Planning Poker as a last resort method of planning. Like "None of the devs have ever done anything similar and noone really wants to give a clear estimate, so lets do some Planning Poker".
Agile was originally introduced to put power back into developers hands that could more accurately determine how long it would take them to complete a task. The issue is that management fought against it at first and finally found ways to change the process to ensure they had the final say. Other problems include senior and jr devs giving estimates based on how complex it is to them - especially if they are subject matter experts.
@@LewisMoten In the first place, "complexity" is a non-measure. It can mean anything and even if you try to bound it by comparing to past tasks done by the team, it still defies that, since everyone has a different idea of what those looked like (since they all worked on different things). Using this has no upsides, especially since actual complexity of a task is something that tends to surface as you do it.
I find it useful as a dev/former qa to keep business side happy. Look at our velocity. WOW. Thing is since they are a completely abstracted unit, business is much happier to let you work and just check in every 2 weeks to see how things are going.
@@deadlypandaghost From my experience, business is usually pretty uninvolved themselves, or at least they try to be. They don't really get what's going on an none but a select few actually want to learn. Most are concerned with how to not take any responsibility in case of problems.
@@Fossil_Frank I feel like if complexity (as independent from time) is a factor in your estimate, you probably need to do a better job of describing the story and documenting the topic. However, one thing that _should_ be considered is the risk; if there are likely to be bugs you'll need to fix and your company only bills the client for stories, maybe round up.
But not complexity in the traditional sense, i.e. "the behavior of a system or model whose components interact in multiple ways and follow local rules, leading to non-linearity, randomness, collective dynamics, hierarchy, and emergence", measurable complexities in programming include things like cyclomatic complexity. Complexity in story point terms is more relative to the programmer, their experience, their perspective on a given task, their familiarity with a codebase etc. So it's and estimate of how difficult they think the task is prior to starting it. Which may or may not be useful.
Complexity is fundamentally a personal subjective feeling. Using different people's subjective feelings to represent it with an even more abstract number or T-shirt size is even more absurd. Since the initial quantification is based on subjective feelings, it would be better to use time units directly.
Sure, and then the PO somehow "translates" them into time and demands to know how is it that a 3 point story wasn't finished in 3 hours, or whatever arbitrary amount he thinks it's "worth". This is the very point - the fact that you don't let devs estimate actual time, means you can then impose whatever deadline you like.
In the end it gets treated the same way as time. It's a way for PMs to ask devs for time estimates without having to directly ask them for time estimates.
@Slukke Estimating story points requires everyone's participation, which wastes time on planning poker. You should also minimize the use of subjective consensus in any management decisions. This is not a group project for elementary students. What is truly needed is someone with a clear understanding of software engineering to make estimations. Of course, there is a chance of errors, but this approach is more accurate and time-saving than using planning poker.
This can definitely come down to the quality of your BA or manager. I had a positive experience with it on my team, we were all generally on the same page and the voting was being performed only by devs and QA, and QA would almost always defer to the devs. It was cohesive. But if you introduced even one toxic person into the mix, I could see it derailing constantly.
We did have planning poker in my previous company. Only devs that would be working on the task (in a sense of "this is a BE task, therefore BE devs vote) voted on the issue, so it was discussion between people that actually knew what the issue is about. I think it was slightly better than the alternative in even earlier job, where teamleader put an hour budget to the tasks and when you went over, you had to explain "why it took you so long" :D
I used to do this and it helped a lot. In most cases when the debate happens you catch something you didn't consider or you clear misconceptions about the work. When done correctly it is very useful
It's wild looking at the actual Agile Manifesto after hearing about how Agile is implemented in a lot of companies because, like... the way so many companies do Agile miss the point so hard that they end up doing the polar opposite of what the manifesto was talking about. The manifesto is all about not having constant unnecessary meetings and having management get out of developers' way and let them focus on actual development, whereas so much stuff with the way many organizations actually implement Agile is just adding layers of gamification and abstraction to constant meetings and micromanagement. I'm reminded of a conversation I had with a technical writer friend regarding this one Business Insider article about a 20-person polycule that adopted Agile to organize time for hashing out relationship issues, and my friend pointed out that they aren't even doing Agile right, since they only do stand-ups once a month. Thinking back to it, I think that polycule was actually the only group of people doing it right.
I used to be a PO for a global company with a lot of dev teams. My teams wanted to use SP and planning poker, but I let each team decide on the SP definition individually of one another and I took the hassle of translating into a roadmap. I never had anything to say in the planning poker and that was intentional on my part, only devs / UX where needed. It worked very well that way. As a PO/PM I still love your content ❤
Best PO I ever had was a former dev in the project he was a PO for. He would stay out of things and let us do our thing but he had a really good idea of what was in the realm of possibility and what wasn't. There were even times no one on the team knew how something worked in the program and we would just ask him in a midsprint and he often remembered.
Having to decide how much points would a task take is painful, usually there's at least one person understimating and it turns very akward to decide the score, adding pressure by the PM/PO to go with the lowest option makes it more painful. Recently moved to a team where the person who's going to do the story gets to decide the points, and the PM is not that intrusive... Honestly it feels refreshing and makes the ceremony a lot less time wasting.
A previous team I was on at my employer used planning poker. It was literally just dev and qa, and the team lead/pm just took the input and guided discussion. Dev voted on dev, qa voted on qa. I imagine if every team was like that, it'd be better accepted.
That's what my team currently does and it's still a waste of time. QA's estimates are wildly different from the dev's, they are non-technical and only think about how many test cases there will need to be, so even a trivial task like, changing a label gets 13's or higher from them, while exploratory issues, without clear bounds get 1's, even though no one knows how much there is to be done in them - but the testers don't see a lot of cases to cover. Dev's on the other hand also have a tendency to overesitmate, since it's better than constantly underestimating, due to not being able to guess the "complexity" of something they have only a few minutes to think about.
Oh wait. My manager during my first internship did this!!! It wasn't too bad since everyone in the team was a developer, and, usually, we all estimated around the same value (well, I say we, but I had no clue what was happening back then lol). My current manager is way more soft with it and I like it way more. The points are up to whoever created the story (usually a dev) and can be updated at any time by whomever the story is assigned to. He'll usually ask why, but mainly because he wants to make sure everything is on track. Worth mentioning that he used to be a dev, too.
And once this 💩💩💩 started, I left the industry 😂 Worked freelance with the hubby, moved to the other time of the planet, and am a full-time musician now 🤘🎤☺️🎹
We have used Scrum in the military, planning events, managing production in maintenance etc. I will say the one point you made about “everyone” voting for each issue was not included. We specifically ensured only people who had an actual hand in the issue actually voted. And also our Scrum master was insanely fast. We would get through a sprint in less than 30 minutes. Max morning meeting was 8 minutes. BTW we had at least 25 people in those meetings. I would argue that Scrum does work when people actually know how to use it effectively. Of course it did fall off when less than capable people started running it.
The idea is, that QA for example have their input on how much it would take to test the tasks. In practice the estimates end up even more wildly divergent, as they have no idea about the technical stuff. The only real way to deal with it is to take their highest vote and add it to the dev's highest. After making sure it's massively overestimated, of course. The PM and PO will still be on your ass, no matter the score, after all.
@@adamfarmer7665 That's a tall order, dude. Devs not only typically don't want to do this kind of menial work, they are expected to develop. Most QAs are non-technical (at least qualification-wise), so they are hired at massively lower costs than a dev. No company would stand for having high-payed staff do the work of low-paid ones instead of their own. Also, it's actually really bad practise to test something you wrote yourself, for many reasons. QA is necessary, I'm not saying they should be removed. It's just the unfortunate reality, that no one hires QA that have a dev background. In truth, you probably wouldn't find many such people, in addition to having to pay them like devs.
@@Fossil_Frank you know more about the thing you wrote than a qa tester that is essentially doing monkey test. If I had a company I would have like only one person doing monkey testing while having multiple devs on QA roles, also I would have the devs wrote tests on the code they wrote for proof of work. At some point it qa testers will be nonexistent due to AI anyways.
@@adamfarmer7665 Yes I do and that's the problem. If I could reliably spot my own errors then I wouldn't make them in the first place. While the concept of "white box testing" exists it's not enough by itself. A dev just has too much bias to test his own work, or even a fellow dev's work. He has a specific picture of how things work in his head and just won't think to try a more "uninformed" scenario, even though it's how a real user would do things. That's why outside perspectives are required. Don't get me wrong, we do write tests for specific parts of code. It's called unit/integration testing depending on the approach. Ideally you do this for every piece of functionality implemented. Still, it's not enough. It's common to have a great test suite for your work, only to get the task back from QA as a failure under some specific circumstances. This might be "monkey testing", but there's just no replacing a person going through a whole lot of trials on the end-user UI and seeing if something breaks. Otherwise you will treat your client as the tester and they tend not to enjoy that.
Never used Agile for 30+ years as a dev, had a rep for good work. Then started Agile and my productivity dropped by 75%. Then retired and every day I say "ha! no sprint meeting today!" and feel great about it. This is just TQM for the '20s. It too shall pass. Or at least it will if we dont want the North Koreans to leapfrog our quality of life.
@@natehill8069 So far it has been infecting everything around, not just programming. I've seen agile lawyers, agile HR, agile controlling... Companies have been infiltrated by cultists, that advocate this bull for anything you can imagine, hell I bet they change their lightbulbs in sprints. It's a method of micromanaging and allows for the existance of highly-compensated but useless jobs. It's too lucrative to just let go of.
So accurate. The two wild things for me were: Brand new employees unfamiliar with the code base were not only allowed to vote, they were demanded to vote even if they would say they didn't feel comfortable guessing. 2) Not a single team could ever agree what story points meant. One might think a 1 is a whole day but another thinks a 1 is a task a low level dev could do in an hour. This means if you have to support multiple teams or manage components of a program between multiple teams when looking at the backlog you have no clue what it means when one team says they can do 100 points per sprint and another team only claims they can do 6. They also argue "points don't equate to time it's level of effort" but what is level of effort if you ask? "How long it takes a developer to do a task, but it's different for each dev." So if a level 1 dev takes 1 day to do a task and a level 4 takes 1 hour to do the same task does that mean other tasks are a 1 point task? If we all agree the average dev takes X time to do X points that means X points = a time meaning the point is a time value and we've come full circle. Story pointing is dumb as heck.
I have yet to see an actual use case for story points where it upgrades productivity and not jus adds another thing to stress about not once has the story point numbers been used to point of areas where we can improve or maybe distribute our work better it’s either the most poorly executed or poorly thought over tool to exist
It can be useful if only deva are voting on it, because one dev may know an easy technique to tackle a problem that others may not, so when they give a lower point estimate than the rest, the task can be assigned to them since they are the most efficient. It quickly gets ruined when non-technical ppl vote tho
Each sprint told how many story points we will be allowed to assign. Then we're told they are not for planning time, but the amount per sprint is based on hours of availability during the sprint. Everyone votes and then I just hope I vote with everyone, so they shut up and I can finally get back to my work
The strength of expressing the size in story points rather than hours is that management cannot hold the team responsible for "not working enough hours" or whatever. The weakness of using stort points is that they lack real meaning. 😂
@@ShortFilmVDWell the honest answer would be probably around x hours but if a major problem comes up maybe 10x hours or more - the hard part about estimating effort to design software is that figuring out what exactly needs to be done ist the biggest part of the job - writing it down is the easy part.
@@robstamm60 estimating is a skill which one can train like any other (IMO). Unforseen things do happen, but estimates can be refined and stakeholders can be updated. Many would prefer to have more accurate and increasingly precise estimates over hand-wavy cop-out quantities, especially when time is money.
@@ShortFilmVD "using the industry standard highlights a lack of professionalism" 🤡 It is only necessary because stakeholders and executives are generally extremely destructive in their handling of development process, causing massive burnout and disrupting the most minute task. All those rituals & processes only exist to keep stakeholders at bay and make them realize that we developers are not a congregation of wizards capable of conjuring up the most complex systems in no time without any preparation. Teams that don't have to deal with that are able to work with simple kanbans
@@ShortFilmVD The problem with that, is that programming isn't like a lot of other types of work. You can't just say "well it too me X time to lay Y number of bricks last week, so it will take me 2X time to lay 2Y bricks next week." Programming is a puzzle you have to solve. Sometimes a seemingly simple puzzle takes days to solve, sometimes a seemingly compiles one ends up being trivial. It's not just a matter of stuff taking a little longer than expected, it's a matter of having essentially no way to know what to expect in the first place. And the reason it's so hard, is because the thing you're working with is too complicated to know perfectly and intimately in it's entirety. Sometimes you can't even guess how to do something until you start trying to do it. I kid you not, I spent the last three days fixing an issue two more senior devs had already spent a ton of time on and could't devote more to. It took two lines of code in the end. But it took an insane amount of time searching for the cause, hunting down evert path, searching the code base for what code handles the thing that's wrong and just trying to understand how it works and why it might not being working correctly. In the end, I committed two whole lines. It looks like I did hardly anything. I couldn't have guessed how long that would take. I could have found it in two hours if I happened by chance to look in the right place, or I could still be searching if I had tried something else. And half or more of the problems devs deal with are like that. Sure, sometimes it's just "do this thing the same as you did that other thing" and sometimes as soon as we hear the task we know just what to do. But most of the time, it's kinda nebulous. You can't measure the complexity of code by volume, you can't measure the productivity of a developer in keystrokes, and you can't expect someone to be able to estimate how long it will take to solve a puzzle they haven't even started to work on. Sometimes a few lines of elegant and efficient code take days to write and make the company millions of dollars. And sometimes the most mundane seeming crap in your system is thousands of lines of crap someone shat out in a day. And half the time, you can't tell which is going to be which until you're almost done.
can confirm this is how it works. Also there's always one guy who is actually going to do the work and knows exactly how long it should take but his vote is just lost amongst the other 10 people who have no idea what the task is even hoping to accomplish.
The issue is not planning poker itself it's non dev/QA voting on it. My company used planning poker for a year or so before switching to different methods to estimate story points. The only people who were allowed to vote were QA or devs. QA needs to be included in task estimation as there can often be a lot more testing work compared to dev work.
And that is why planning poker in my teams was always debate between people who actually working on it and have a valid reason why it is more complex, as not every story is complex in code but around it. Your team requires brains to work good. Story poker does not prevent stupidity.
Only developers should vote on story points. Story points should have base references. Anything above 13 should be broken into smaller tasks. Story points should be tracked and time per story point should be tracked. You limit number of story points per sprint. If done well, it is great for planing, but it's good only for planing and giving timelines to higher ups. If done bad is a colossal waste of time and can lead to various issues.
If you're creating something from scratch then I can imagine the complexity estimate might make sense as group think. But if Fred has never been in the code for area X before and Helen has (and knows its FUBAR) then Helen's opinion is way more likely to have merit, when working on improving something - even among just devs. The only companies I've ever worked for have had some very interesting legacy stuff lurking behind the curtains from when computing in general was this new fangled thingy.
The most successful team I ever worked for got rid of story points. We were a kanban team that basically chunked our work down so it was at most a day or so. Development was so smooth and the tickets would whip across the board. Merge conflicts never happened because we integrated our work almost every day.
The weird thing is that story points represents complexity, but managers like to convert them back into hours/days for velocity reporting and other metrics. I’ve heard people using buckets of sand since sand can overflow the buckets. I’ve seen lots - like menial tasks given many story points to cover code review, testing and QA just for fixing a typo. One manager/scrum master would argue with the teams choice of story points saying it was too high, and complained when the task wasn’t complete on time, and blamed the developers for not being persuasive enough to convince her about their decision. We often had hour-long standup meetings and lots of blame storming. Managers were on a separate floor above and there was plenty of contention between developers and managers. One manager decided to promise a deliverable for a clients birthday, which put a crazy amount of stress and overtime on developers, to which managers never had to stay late or come in on weekends.
yup, instead of using the experts who are doing the work to give their say and explain why they always put double the time down is the situation that usually happens. Where they need to troubleshoot the problems and it will take a lot time but if there is no troubleshooting to fix any bugs great the job get done very early. This way they have more time to test the system to make more improvement or get it to the client earlier. I think it is a better way to work.
I feel really fortunate, my company isn't a tech company but outside the top lead manager for the tech division, all the leadership came from a tech background so even the higher managers have more realistic expectations even if they haven't actively coded in 10 years, both my manager and his boss actively are required to code a few times a year, so direct managers can stay up to date with recent tech this way which is nice.
Actually, I believe there's a better use for story points, and it's to make sure everyone understands the complexity, and therefore, make sure that everyone is on the same page. There can be many details that some thought of, but others dismissed, so it is a great opportunity to clarify these things. Also, story points are relative to past experiences.
How do you "make sure everyone understands complexity"? Do you expect that there's someone among the devs that did this exact thing before and can just walk everyone though it? Then just assign them the task and be done with it. Planning is not meant to be debate time, refinements are for that. Also, it needs to be done at the time of formulating the task, so that nothing gleaned is lost to the chatter. As for "past experiances" - unless the task is really run-of-the-mill, they don't help that much with estimating. The guys that insist otherwise always end up surprised about how much they missed the mark.
Story points have been very beneficial for me. There used to be a time when we had to really watch out to not get over our estimated hours, or we’d have to justify ourselves. Now we use story points and they’re not officially worth a specific amount of time, so we’ve got more leeway with how long we can take :)
So, i love these videos. Love your content. I am a certified scrum master. I have never seen the powers of 2 scale used or even discussed. Every single video is about how agile goes wrong. Planning poker is a tool that forces a discussion. I can not stand it. Just have a discussion. Ask the question, what is involed to get this done? Same result, 5 times quicker.
@@kirishima638 Yes, but when it gets down to the planning phase you are discussing with developers for the most part. Basing it off of effort for a developer is more valuable. Everyone knows if you ask 10 developers how long something will take you'll get a different answer each time. Ask the same 10 how much effort it is, you'll get a better set of answers, some being the same. Relaying back up to the business how LONG something will take should be based on the sprint goals not individual task and story points. If done properly, you'll be able to see the burn down and track the progress as well. Very easy to fall into effort == time (and to some degree it is) but a clear distinction, especially when planning is a must.
I've refused to have an opinion on story points when I had no clue what was involved in the process. This should be encouraged. When enough people can't decide, you set aside some research time. It could turn out to be a simple half point story, or it could be a monster 13 points.
Yeah, but no company will stand for that. An accurate estimate would require at least a day of checking it out from all angles. No one has ever agreed to even 2 hours out of the usual grinder, in my experience.
We do story points just between devs + tester and it's plenty useful. Our PO's approach is "I tell you what we need, you tell me how long, I don't care for the technical details and can't fight you on that so I don't care for how you get to the estimate"
Yeah, and when shit is close to the fan, he somehow "converted" the points to the time he thinks they're worth. A time that lets him meet whatever unreasonable deadline that the stakeholders hoisted. That's the whole purpose of using story points - if you let dev's estimate in time, then it's harder to make them crunch it later.
Senior engineer here. I've yet to be in a situation where non-engineers are voting, but I wouldn't necessarily see that as a bad thing. This would be a nice point to catch when the task is more complex than its priority warrants, such that the scope should be changed, and them asserting what they thought the task would take is a good finger in the wind indicator for that.
I'm a PM and we do planning poker. I never vote and would let anyone but a dev vote. We break down the tickets in tech refinement into smaller tasks and estimate these. We don't really have to test all the subtasks, just the task itself. But it forces the team to think about the implementation before we're kicking off the development. This doesn't really help when everything is obv. But it helped us a lot doing more complex tasks, where we spotted issues not anticipated before. I was able to clarify more things or the devs would realise the approach wouldn't work and come up with an alternative. Thats why i like it. Story points on the other hand is kinda OK. We use it to allocate a rough 50/50 split of new features and work on bugs. It seems sometimes teams forget they are being held accountable by their management. PMs and Techleads make commitments and it's just natural to keep track of the progress and understand how much work is left. While Jira can show the progress, rarely do i see management use it to actually check in on it.
I really enjoyed planning poker when we used it on one project. The project was 2 years late and $1 million over budget, but the project team at least understood why the whole time. The trouble with agile development generally is that you get a timeline and budget BEFORE the planning is done, so they don't have any grounding in reality.
I was a PM for a few years - I don’t think I was as bad as Cindy and I also hated story points and planning poker etc but we had to do it per company mandate all teams did. But since we all hated it we’d just vote and then if there was disagreement I’d just look at what the most senior engineer said and ask if everyone was OK with that and 99% of the time they’d say OK and we’d move on. SCRUM is a cult and I’m sorry for anyone still stuck in it
To be honest, it is a good way to quantify work for a task. Sometimes juniors will over- or undershoot the story point estimate and seniors can point out steps thats can either speed up or slow down the task.
As a teamlead i can say that storypoints and velocity chart are the best tools to tell a business that with current resources we can do a certain amount of work. This allows the business to work more actively with priorities, negotiate compromise solutions with the customer and at the same time not stifle developers with estimates
I'm doing my pm training now and I laughed when I saw planning poker as I immediately saw the BS that would come with something like that. Glad I'm correct on my assumption. Love your shorts man
Even if you're very familiar, if the task requires any brainwork at all (as opposed to standard things like CRUD), then there's no accurate estimate that you could put your name on with confidence. Not when you're expected to come up with it after just seeing the task for a moment.
As many other things, the problem does not lie within the tool, but within the people using it. First, only doers get to vote, and if you are unsure, you don't push for a debate. a good Scrum Master or team discipline will make it smooth. I've had an awesome Scrum Master once, and it worked wonderfully. After a couple of adjustment sprint, we had a mutual understanding of what 3, 5 or 8 mean, our velocity were consistently around 45 story points per sprint for 3 devs. No pressure to add more than our capacity, no pressure to overestimate either, the progress was clear, there were other problems, but no one was complaining about lack of visibility on our progress and delivery
The way I was taught scrum and how it was done at the company I worked in was far less stupid and actually worked well for all parties involved: Tickets were marked between 1-5 story points depending on expected complexity or time invest needed. This was done inside the dev team once every two weeks in the following order: First a ticket was discussed, if there where questions (PO or person who wrote it moderated this part) if all were fine and understood the requirements, every dev (and QA) would at the same time vote showing 1-5 fingers and if there was much discrepency between them shortly discuss their reasons and Dev estimates had a higher weight if that still didnt solve it but 95% of the time the estimates were identical or just one point difference. The points were then used by the PO to figure out which and how many Tickets can be included in the coming sprint. This worked amazingly well, sprint planning was on point nearly every time and the whole process took maybe 10seconds per ticket.
I still don't get what value it bring? Let's say you bring 4 ticket into the sprint? But it takes more time, then what? Also what if you are done with the 4 tickets midway then what? And how much work could you do instead of planning?
@@Tldr205 we had Sprints with 50+ SP so quite a lot of tickets at once per sprint, to get an overview of that is otherwise pretty much impossible. Using SP in that sense is simplifying the process of time estimation, people (humans) are horribad at guessing accurate time, but given a 5 point scale and thus relation is easier, faster and actually more accurate to use for overall workload estimation. If you run out: there's a lane of tickets waiting with lower priority. If you don't make it: leftover tickets are moved to the next sprint, easy. How much work you could have done instead: given that the discussion of tickets part should be done either way, worst case we "lost" 15-20min a month and compared to other teams I've worked with, the gain in productivity and planing security, was easily in the hours a week range.
@@shezario interesting and thx for answering. I still fail to understand what value the assignment of SP bring (I'm on board with how SP works that it is a measure of complexity and not time). Did you do something different if it was voted a high vs low? Or did you have a max too as how many high tickets you could bring? And why not just prioritese the tickets work on em from highest to lowest regardless of complexity? I have not worked in a place we had so many tickets so I'm asking to understand 😊
I'm on a T3 support team for my company's customer facing payments platform. When we point stories it is just the team that the story board item is assigned to. I couldnt imagine including non-software engineers in our conversations, especially when code changes are involved.
The last part is the actual stupid part. I've done this in my previous job, but only swe were voting and only if they feel they knew how long it would take. That was pretty quick even when there was discussion, and pretty correct in the end. Half a day top every 2 weeks. Then we had new managers and PMs that added meetings and processes and unfounded opinions. Suffered for too many months and I left while everything went to shit.
In my team, story points are only decided by the people who actually work on the tasks. I feel like this makes it a bit easier, and for most smaller tasks, we don't make a group session out of it.
So here's the thing: story points can work if you go for complexity of a task rather than time to get it done. Then all of a sudden it can happen that people actually learn "oh hey there's a thing I didn't think about here that makes this super hard/easy" and then you can for example break it down into smaller workable chunks
The real issue here, besides the extra meeting, is that people think points is a measure of time.. but it’s actually a measure of complexity and unknowns
My experience has been the sort of opposite - the outlyer tends to be higher and is a Dev or Tester When asked its generally like it's a complete re-write or you need to regression test a load of other functions and that sways the outcome Remember pre-Agile - you would be given X days to do the work becuase that fitted the pre-approved timeline which had been agreed by the Business/PM to get delivery on the date they wanted
The point I think is to uncover if some dev thinks a long task can be done quickly or vice versa. Either the outlier didn’t realize that the task consists of more than he thought, or the others didn’t see the easy way to solve something, either way that’s the value I think, to help have this discussion with multiple devs. This doesn’t happen when you just ask „so does everyone understand the task“, but with planning poker this gets uncovered. That’s how we are using it, but we’re not doing anything with the actual estimation, so there is no fight on who is right.
Gamifying deadline estimates like this is akin to a therapist advocating using dolls in their practice to get adult clients to share private thoughts and feeling with their S.O.
All planning I've had has only ever had devs/testers input for estimates. That said many devs are basically clueless especially if it's projects they haven't touched before or skill sets they don't have. Story points work in a very very very narrow margin of teams that actually understand agile but for the purposes of the real world, that's nearly nearly always zero. The reality is that there's always some translation to a time unit, in my first job 3 story points was 1 day (although they were better than most in this regard), my next position was different and I can't remember! Ultimately I feel like it's a bad tool and we need to abandon it because I've never seen any bloody value in trajectory or whatever it is ever.
I like story points to be honest. It gives a ballpark estimate of how long the story is going to take from beginning to end. Anybody that has potential to be executing work on the story should be voting on it. I'm too dumb to know how long or how difficult something is it going to be alone. The last time I put story points alone I put three on what in hindsight I should have put five on.
This "ballpark" means both nothing and anything you could imagine. It's common for 30 pt. tasks to be finished in a day and 3 pt. ones in a week or more. This is both due to wrong estimates (we only get to think about it for a few minutes, we'd need at least a day to be accurate) and the fact that "complexity" is a non-measure that cannot be forseen in general, much less quantified in time.
@@Fossil_Frank I don't commonly see that. Our point ranges have been one through 8 Fibonacci. We split them up if it's about an eight. It's not perfect and it doesn't guarantee a specific range of time. But if you take averages you'll find the massive difference between one 2358. In fact given these are estimates I'm not sure what exactly your suggesting. Are you suggesting ten 1 pointer stories took about the same amount of time as ten three pointer stories? If so then your team might be estimating wrong. Or maybe they are estimating correctly in that is how the majority prefer it. Or maybe estimating story points is not for your team and something else is. Or maybe any sort of estimation is not for your team at all. None of these things are bad or wrong. It's whatever gives you the most velocity that is also accurate. I just happened to be on team story points so I may not be best for your team.
@@Omego2K It's not really about the team, this is a common problem I've seen across many projects and companies. The projects I'm involved in tend to be about fairly non-typical systems with special requirements and a good deal of exploratory work to be done. Giving estimates (beyond "we expect to be mostly done with X next month" - this never satisfies anyone) for such things is just a waste of time, but management still insists we do it. Inevitably those estimates are mostly worthless, which is an endless source of arguments. Also, we don't have the option to chop up tasks to such small parts, it wouldn't make any sense in this context. In fact, I strongly argue that the whole "agile" cult has no business existing in projects like that, but no manager wants to hear that. They'd rather hear that the team is having trouble, because they aren't using agile "right". The thing is, no one knows what hoe to use it right. If you adapt it and change the rules to suit you - you'll hear it failed because it wasn't pure agile. If you go by the book to the letter and it fails - then the explanation is that you should have adapted it to work for you. There's just no winning here. The concept itself is a deity for those people. Infallible, but always used incorrectly.
@@Fossil_Frank I don't understand then. Agile is a framework with many different implementations. However, you don't have to use it and in fact if you have a better solution you can certainly start your own firm or work for one that implemented the way you prefer it. I mean if the way you think it is best to be done works then you must be able to make a broader income from it given everybody else is doing it wrong. In fact you can be a Hired gun. There are people that don't charge hourly but weekly and make 20 grand a week because their skills are so high in demand. I feel like this is something that you can accomplish given you see the flaws in the work stream others are using. Is there really no business that thinks your skills are worth 20 grand a week? I mean if you work for 10 weeks a year you're making 200 Grand. Think about it it sounds like something you're adapt for
@@Omego2K Dude, can you even read with any kind of comprehension? I never said I see flaws in everyone's way of work. I said the kind of work my teams do is unsuited to agile and the amount of conflicts generated are a testament to that. Are you that much of a scrum cultist, that the very notion that there are classes of projects, for which it fundamentaly fails offends you? Even worse, your rebuttal is "go start your own company then, since you know better than everyone!". That's so fucking juvenile I can't believe you work in this industry... Go on then, put your money where your mouth is and take your own advice. I mean, you claim that the correct way of doing things is right in front of my face - surely it'll be no trouble at all to imitate it and succeed yourself then? It's the least you can do before advising a "rebel" like myself to go challenge not only the whole industry, but also the proper methodology, right?
I had a whole conversation about this with someone. It went something like this: “What’s wrong with just using time estimates? Time is the great constraint, right? And it’s what management wants anyway.” “Story points are not time, they are a sort of complexity score.” “But you guys budget x points per sprint, which is 2 weeks, right?” “Right.” “So it’s time, actually.” “No, you don’t understand.” This will seem like common sense to some, and an alien language to others - the reason for points is so the process can scale to fit your iteration size. It’s still time.
For my capstone project at college we did our first 2 sprints trying to give realistic story points to tasks and since we completed things ahead of schedule it actually started making our burn down chart look worse in JIRA. So to compensate we just made every single thing 8 story points and if it was harder it was 11. Then every minor task made our burn down chart look better.
Where I worked for my last internship, we just assigned a value from (0.25 - whatever), allowing us to do like 1.5 days of work if we find that the ticket should take that much time. Our PM was also a SWE, so life was great there.
unpopular opinion: in our team we used to do planning poker too. i enjoyed it. we were a really small team and planning poker helped to find out in a relatively quick manner if everyone in the team roughly understands the task the same way. of course it doesnt work all times, but while we did that we had way less discussions in the daily about what the actual content of an issue was. but of course there are a thousand ways of doing things wrong, and not everything fits for the same team. in the mean time we stopped using story points, but i feel like sometimes it was genuinely useful. and no, PM and agile master didn't vote, only us software engineers.
As a PM I had clients who insisted on assigning story points to any work, but I would never do it (or let anyone outside dev team) bonus is that if clients ever complained about speed I can always throw it back at them "well that just how many story points we can fit"
Scrum introduced a quite dumb thing: use story point instead of time. I could say that this task would take 2 days, but I am not allowed to say that. Instead I have to say that this task is 5 story points. When I asked back about what does did mean, they just said: complexity. Okaaay... But complexity means efforts and time, right? Nope... Complexity means how difficult the task is, and it even doesn't contains how many times you have to repeat it on different data or piece of code. That was the WTF moment for me, and I just said "whatever"... Hopefully, I haven't had to work with this BS system again at this level in the last ten years.
Time is a terrible quantifier of effort though: an ace developer can spend days or weeks stuck on one tricky issue when they could have spent the same effort implementing several new features.
While story point are very annoying - if you have a bigger team, planning poker is useful, because when you ask people who gave min/max, you can get great insights on corner cases of the story and potential hacks etc that can be used to make the job easier.
In theory. In my experience the domain expert who says a feature is 10 points instead of 2 just gets pressured and called a pessimist. Estimates should be made by the domain expert exclusively, not managers or testers who just ‘think it should be easy’.
