When I first moved into management, I wrote an article about how my direct reports could get more value out of our 1:1s. I'd probably write something different now, but the broad strokes remain true. https://erik.wiffin.com/posts/how-to-get-the-most-out-of-you...
1. Don't make it a status update. It's your time, and that's probably not the best use of it.
2. Spend some time figuring out what you want to get out of our 1:1s. If you don't know, tell me that, and I'm happy to work with you to figure it out.
3. End the conversation with next steps/action items. It's easy for me to say something that you interpret as a promise even if I didn't mean it that way and calling out action items explicitly is a good way to keep that from exploding into a huge problem.
This is asking a lot from you, but in your situation, I think your goal should be to build up enough of a relationship with your manager that you feel comfortable telling them that, or realize that that's never going to happen at your current company and find a new job.
I have reports who have told me that they're happy doing what they're doing. I don't see it as a negative at all - they're employees who are quietly getting their job done and I don't have to worry about them leaving for career growth or Peter Principle-ing them into incompetence. It's important that we continue to have 1:1s though. People aren't static, they can change their mind, and I also want to make sure I keep an ear out for little things that are annoying them, and do what I can to make them go away.
That’s good for you. But how good is it for them for you not to inform them of the existential risks of them not getting better at their job and staying marketable? Even if they don’t want a raise? Every industry goes through changes and you should encourage them to stay up to date on those changes instead of just chugging along on the legacy products.
I met two developers in 2016 who had been with the same company for 10 and 17 years respectively maintaining a PowerBuilder app from 1999 running on Sql server 2003.
The company was happy to let them keep chugging along until the company got acquired by venture capital and they said they “no longer wanted to be a software company”. How do you think that worked out for them?
I think there's value in that debate (within reason) even as a developer. If Alice thinks a task is worth 5, and Bob thinks it's worth 8, then there's a good chance one of them knows something the other does not. Is Bob aware of some hidden complexity that bumps it up 3 points? Or is Alice familiar with a convenient library that solves exactly that complexity? Planning poker is a convenient time to get that knowledge out into the open.
Again, this is all within reason, and if it takes 15 minutes on every ticket, the team should probably work on their communication skills.
Everyone is correct in this thread. The stimulation of discussion is useful, and numbers are arbitrary.
Instead of worrying about 5 vs 8 though, the team should be discussing relative difficulty: is story B easier/more difficult/complex than story A? And then ranking stories based on the relative difficulty of each other.
Story points can then be derived based on that ranking, if the team chooses. They're useful for being applied to velocity calculation, and also helpful when picking up a story to work on (maybe a bad idea to start an 8 pointer on a Friday).
(I have a SM cert, working as a TPM. I applying Agile principles to teams, but modified to how they want to work and be most effective. No militant Scrum here.)
That for sure seems useful. "Hey Sally, you think B is harder than A. Why do you think it's hard?" "Hey Bob, you disagreed with Sally and think B is easier, why is that?"...is very likely to lead to a useful conversation in terms of everyone getting in sync and may well lead to hidden information being brought out into the open, which is a good thing. In general I think relative value/preference type conversations tend to reveal a lot.
Attention! Discussing story points is no longer allowed during planning. After voting, teams are to discuss relative story points, swapping points between each two story. This is expected to increase efficiency and coherence. Rule enforcement commencing beginning of next month after the first weekend.
My experience is that in well-running teams, devs are usually pretty aligned what these numbers mean. A difference in proposed points for some task does then usually mean there's a discrepancy in knowledge about it.
As for its usefulness: You of course don't have to necessarily poker to get these discrepancies, but it's a pretty effective way of going about it, I'd say.
Exactly this. It's probably not an accident that one of those numbers is half of 10 (and the number of fingers on one hand) – a common made-up number for everybody – and the other is 2^3 – a common made-up number for programmers.
I've always done planning poker with the Fibonacci sequence - 1, 2, 3, 5, 8. The idea being that the more complicated the task, the harder it is to estimate accurately.
Why is story point estimation tied to fibonacci sequence? Two generations of managers at my previous employment thought this way. It just seems so arbitrary to me.
First, the more difficult a task is, the more inherent difficulty there will be in "accurately" estimating the difficulty of the task. Fibonacci is used to represent the inherent lack of accuracy in more difficult tasks, since the numbers get _very_ far from each other as they go up the scale.
Second, the numbers _are_ arbitrary. Completely, 100% arbitrary. It's a _relative_ difficulty scale. Say you've got 3 tasks - A, B, and C. A and B are approximately as hard as each other, they're 1 story point. C is more difficult than either one - it gets 2 points. That's it. Story points are not, and should not be used as, a unit of measurement. The biggest utility is to identify big, scary tasks with lots of unknown factors.
The fact that they are _numbers_ is what tricks so many teams/PMs/management/etc into thinking that story points are more meaningful than they were ever supposed to be. Incidentally, this is also why some planning poker teams use t-shirt sizing (S,M,L,XL,XXL, etc). No numbers means people are less tempted to punch them into a spreadsheet while deluding themselves into believing that showing numbers going down is the same thing as "showing progress".
The closer the numbers are together the more time is wasted trying to be exact about them. Fib helps reduce the amount of back and forth. If you need to guess how much something weighs and your options are 1,2,3,4,5,6,7,8,9,10,11,12,13,14.....100, you are going to have a lot harder time achieving consensus than if you asks "Is it heavier or lighter than a breadbox?"
My team doesn't really argue about points next to each other (on the Fibonacci scale) anymore, we just pick by majority and move on.
The conversation is meaningful when it's about 3 vs 8 because exactly as you say, there probably is some hidden complexity not everyone knows about, or sometimes some work has already been done or there's a framework feature that makes it easier than it seems.
But 2 vs 3 or 5 vs 8... this is explicitly designed to be an imprecise number, so let's not waste our time debating which one to choose.
My team has a rule that if your Fibonacci point estimates are within one of a given unit, you just accept that estimate with no discussion - so if I think a story is a 3, and others think 5 and 8, we’ll take the 5 and move on. I think it gives a good balance of discouraging hair splitting and surfacing cases where having more discussion is actually valuable.
If you will do something different with a 5 than with an 8 then yes. If not, then the ambiguities you describe will be worked out when you do the work. It is just a vanity metrics if the results doesn't change what you work on next. It seems important but it has no actual bearing on the teams sequencing of the work.
If Bob had a plan for doing the work that didn't involve Alice's library, there's a good chance he would have just jumped straight in to implementation without talking to anyone, and maybe the library wouldn't have come up until code review (if at all). By identifying the complexity mismatch ahead of time, they saved 3 points worth of effort. This doesn't affect sequencing at all, but still seems valuable to me.
Or Alice is more familiar with that section of the code and would move more quickly in there and Bob would be doing more learning along the way.
Quick discussion of the differences is useful, but 15 minutes is ridiculous. Just take the higher value and move on. Eventually you’ll baseline at slightly more points per sprint on average, but they are imaginary numbers anyway and not really comparable across teams.
One of the things I noticed is that all of the "how to be a good developer" books/blogs/etc felt much more targeted at product orgs - there's a real lack of "advice" for people working at agencies. That being said, maybe I just don't know where to look, and someone in this thread will point me in the right direction.
It may be the worst domain name ever, but the site only exists because I thought that using "0" as a subdomain was a neat trick, and worked back from there to figure out what to do with it.
FWIW - the only way I can ever find my own website is by searching for it in my github repositories. So I definitely agree, it's not a terribly memorable domain.
That's interesting, I had no idea. There's probably a way more detailed Rosetta Code style project that could cover all these nuances, but for a single page demo, there's only so much detail I can get into before it would be more confusing than helpful.
If you'd like to flesh out the perl section a bit though, maybe include the differences between 5 and 6, I'd be happy to merge a pull request.
You've had a perl6 pull request outstanding for a while. The differences are far too big to list simply though. Ultimately Perl6 uses Rationals by default, not Floats.
1. Don't make it a status update. It's your time, and that's probably not the best use of it. 2. Spend some time figuring out what you want to get out of our 1:1s. If you don't know, tell me that, and I'm happy to work with you to figure it out. 3. End the conversation with next steps/action items. It's easy for me to say something that you interpret as a promise even if I didn't mean it that way and calling out action items explicitly is a good way to keep that from exploding into a huge problem.