61–70 of 78 posts
i would prefer sunny days off, and bad weather days for meetings.
But how would you synchronize the poor weather days of Seattle with the nice days the Bay Area?
Then again, it’s definitely something I miss from doing research at school. Nice day, go for a hike. Bad day, time to finally rerun those experiments. Sadly, I have way more meetings than those days...
Earlier quoted context omitted.
So another way to filter out or alienate older employees or those with families.
And what about us who are night owls and are non-functional until about 12 / 1-2PM, the current system filters out all of us. The solution was literally “come in any time you want as long as your projects get done” - what’s your objection? That everybody who wants to come in at lunchtime, and work until the small hours force themselves around your schedule because you have a family?
Even jobs that are quite flexible are going to want some overlap time and, even if an atypical schedule allows for a few hours of overlap, the reality is that people will get tired of always having to schedule around your preferences.
I worked for a startup that had an internal "story point meter" that would go up as you closed your tickets. The goal was to pressure employees into completing a certain number of story points per week the CEO considered a good number for a productive employee. Needless to say, this didn't work as intended, and the workforce was split between those who didn't care about it (higher ups) and those who maxed up their me…
As a software engineering manager, I put a story-point-based method of task size estimation and team velocity measurement in place about two years ago. A stipulation of this was that at no time would any one developer have their story point velocity assessed. The purpose of this system is to provide the team with a powerful tool that it needs in order to set a realistic timeline on team deliverables, such as a launch…
That gives you both time (min, max, which is the information you need) as well as the risk (distance between min and max).
Then countermeasures could be taken to reduce the risk, until min and max are reasonably close.
Sometimes max is +infinity when there is 0 knowledge, but even that information is useful: missing a role or need research.
Earlier quoted context omitted.
And what about us who are night owls and are non-functional until about 12 / 1-2PM, the current system filters out all of us. The solution was literally “come in any time you want as long as your projects get done” - what’s your objection? That everybody who wants to come in at lunchtime, and work until the small hours force themselves around your schedule because you have a family?
The issue is that there are very few jobs where you can basically ignore the rest of the world (or even the rest of the world in nearby timezones). If you're a solo writer or programmer sure. But if you work with other people, not wanting to have meetings before 2pm is often a problem. (As would someone who wanted to work midnight to 8am.) Even jobs that are quite flexible are going to want some overlap time and, eve…
Earlier quoted context omitted.
As a software engineering manager, I put a story-point-based method of task size estimation and team velocity measurement in place about two years ago. A stipulation of this was that at no time would any one developer have their story point velocity assessed. The purpose of this system is to provide the team with a powerful tool that it needs in order to set a realistic timeline on team deliverables, such as a launch…
Have story points been useful to you, even when incentives are aligned? I find that they're often orders of magnitude off, in either direction.
When not focused on just one objective and not under deadline pressure, the team's average story point velocity per week was 30. This was when we tracked anything and everything we did. When we've track against a launch, where we only focused on the minimum set of tasks we needed to meet a clearly-defined objective with inter-team dependencies and a deadline, the team's average velocity has been 12.
We don't use story points alone in forecasting timelines. What we do is presume a per-dev weekly velocity of (12 / team size). With all of the tasks on a chart, we work with the team to assign tasks to individuals, and we create a strawman schedule for how all the work gets done to meet the timeline. The "length" of each bug is a function of (12 / time size). We track and reassess how all the tasks are coming along on a weekly basis, with the understanding that the "strawman" schedule will end up looking different than we initially project.
For example, take a team size of 6. Then the story points per week per dev is (12 / 6 = 2). Story points per weekday is (2 / 5). So for a task of size 3, we expect one dev to take ((5 / 2) * 3 = 7.5) days to complete, and so the length of the task on the timeline is (rounded up) 8 days.
Then we bring the "fudge factors" into play. For the devs who are more productive we tend to schedule them back-to-back with the tasks that are more urgent and/or are blockers. For the devs that tend to need more time, we keep a lot of whitespace between the end of their assigned tasks and the deadline.
The only time this methodology has gotten us into trouble is when we've caved to pressure by upper management to say we can actually do 15 story points per week or whatever. The most important thing is to measure actual velocity under as similar conditions as you can, and then refuse to accept any projection with a velocity other than you've actually observed. Story points are opaque outside of your team, and upper management is usually satisfied when you translate the story points into the schedule using the method I described.
Earlier quoted context omitted.
As a software engineering manager, I put a story-point-based method of task size estimation and team velocity measurement in place about two years ago. A stipulation of this was that at no time would any one developer have their story point velocity assessed. The purpose of this system is to provide the team with a powerful tool that it needs in order to set a realistic timeline on team deliverables, such as a launch…
I’d argue the predictive power of story point methodology has not been established. There are simply too many variables to make estimates more accurate than “best guess”: 1/ the team’s composition at a point in time (and all the variability that comes with this) 2/ the team’s dependencies (a kind of exponential effect is at work here: the team’s dependencies also have all these issues in variability and so do their d…
Having a concrete plan ("micromanagement?") for getting to the finish line is important, and the story point methodology is an intuitive tool for figuring out what lengths the tasks need to start out with on the timeline.
Earlier quoted context omitted.
As a software engineering manager, I put a story-point-based method of task size estimation and team velocity measurement in place about two years ago. A stipulation of this was that at no time would any one developer have their story point velocity assessed. The purpose of this system is to provide the team with a powerful tool that it needs in order to set a realistic timeline on team deliverables, such as a launch…
What about replacing story points with time ranges? That gives you both time (min, max, which is the information you need) as well as the risk (distance between min and max). Then countermeasures could be taken to reduce the risk, until min and max are reasonably close. Sometimes max is +infinity when there is 0 knowledge, but even that information is useful: missing a role or need research.
Earlier quoted context omitted.
In tech, it is people who work late who act superior. Early birds have it rather harder as they are seen as leaving early even if they objectively done more work.
How can you act superior if the early-birds have already left? In contrast, early-birds act superior while you are there.
Earlier quoted context omitted.
What about replacing story points with time ranges? That gives you both time (min, max, which is the information you need) as well as the risk (distance between min and max). Then countermeasures could be taken to reduce the risk, until min and max are reasonably close. Sometimes max is +infinity when there is 0 knowledge, but even that information is useful: missing a role or need research.
My team uses story points as an input into a time range function.
My main problem with points is the impossibility to represent: - A long task of 5 days that's very well known, it's 5 days of work - A short task that's very uncertain. It could be a one line change or many days of work
With time range, you can represent that and it's very visible. With points, you can represent that as the same points, but that does not reflect reality, one of the two estimates is potentially wrong. This also helps providing input on what research tasks should be performed and what's their value.
Earlier quoted context omitted.
My team uses story points as an input into a time range function.
How does it split the time from the risk? My main problem with points is the impossibility to represent: - A long task of 5 days that's very well known, it's 5 days of work - A short task that's very uncertain. It could be a one line change or many days of work With time range, you can represent that and it's very visible. With points, you can represent that as the same points, but that does not reflect reality, one…
I've found that upper management doesn't care whether any given task actually takes 3 days when we estimate it at 3 days. They just want to see a schedule where each task is estimated to take X days. It communicates that you've really thought through the plan. Then, in terms of results, what they really care about is that we track to the date we committed to for the overall effort.
If a senior director is drilling down into a schedule and asking, "Why is this 5-day task taking Bob 7 days to finish?" that's a strong signal that it's time to change your management.