Page MenuHomePhabricator

Allow story points to just be task count
Open, Needs TriagePublic

Description

Some teams are confident that they can evenly size tasks, and that part of the job of an engineering manager is to so to protect individual contributors from spending all of their time estimating how many points something is. At some point at a previous company Very Into Points one of our team leads created side by side tasks/point burndowns for each sprint, and the simple task count ones were just as good.

Anyway, these would still like a progress bar for a sprint even if they are not using points. I don't have a strong opinion on "display bar without points" or "tasks can have a default point value" as approaches.

Event Timeline

cburroughs added a project: Restricted Project.
cburroughs moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.May 3 2016, 6:48 PM
chad renamed this task from allow progress bar to be displayed without using Points to Allow story points to just be task count.May 3 2016, 6:48 PM
chad added a subscriber: chad.May 3 2016, 6:50 PM

Uuuuggggh. Hold on, are you asking to have task count be "story points" on some projects, but "story points" be "story points" on others?

chad added a subscriber: epriestley.May 3 2016, 6:55 PM

If it's just a global setting baked into 'story points', it seems reasonable, but I recall we (or maybe just @epriestley) thought this was a bad idea™

You can set a global default in Edit TaskConfigure FormEdit Form ConfigurationChange Default ValuesType Some NumberSave Defaults.

chad added a comment.May 3 2016, 6:57 PM

Evan's brain is more brain than my brain today.

Some teams are confident that they can evenly size tasks

(Also, do you know if this is this empirically true, for "normal" software engineering sorts of tasks? I believe this is remarkable achievement if it is.)

...and the simple task count ones were just as good

Oh, I read to the end of the sentence.

chad added a comment.May 3 2016, 7:07 PM

At least the default seems better, since they can change it in cases where it's not correct.

You can set a global default in...

oh, I was looking in /configmaniphest.pointstrying to add something like "default"

In T10915#173710, @chad wrote:

Uuuuggggh. Hold on, are you asking to have task count be "story points" on some projects, but "story points" be "story points" on others?

Well, Right Now I would be happy with "tasks as points" globally. But I'd be a little worried if that meant I had to tell a team they could never use "points as points" later. Setting the default in all forms will probably spark a philosophical argument over what "normal" is but sounds reasonable.

(Also, do you know if this is this empirically true, for "normal" software engineering sorts of tasks? I believe this is remarkable achievement if it is.)

You read to the end of the sentence faster than I could generate a new one.

There has been some discussion about this request in T120042. It would be very useful to some teams that I work with as an Agile Coach for them to have the ability to limit work in process in columns by number of tasks rather than points. That is their workflow which Phab used to support, and the change has led to some confusion about how much work is in process.

So if there is a way to prioritize this feature request, we would be grateful. Thanks!

chad added a comment.Aug 2 2016, 6:08 PM

You can set a global default in Edit TaskConfigure FormEdit Form ConfigurationChange Default ValuesType Some NumberSave Defaults.

@chad Thanks! And thanks to @epriestley, too. When I tried that, I got error "You do not have permission to configure forms for this application"

chad added a comment.Aug 2 2016, 6:18 PM

You should talk to whoever administrates your install. They may have it locked.

ksmith added a subscriber: ksmith.Aug 2 2016, 7:12 PM

The specific request of the WMF teams is for the workboard column WIP limit to be measured in task count rather than story points. We have been directed to this task for that request, although it's not clear to me that they are actually the same thing. We really don't want to treat tasks as if they had a story point value of 1.

For our case, defaulting every story's points to 1 might be an adequate workaround, but it's not really what WMF teams have asked for want:

  • Teams might want to estimate some stories, but might also want the per-column WIP limits to be applied based on task counts rather than story points.
  • Also, jamming an estimate of 1 into every task would make it painful to switch later if a team decided they did want to start doing real estimations.

Just to clarify, workboard columns with a limit should currently show text like this in the header:

[ X | Y / Z ]

...where X is the task count, Y is the point count, and Z is the point limit. Here's an example:

This is showing 2 tasks, totaling 0 points of a limit of 3 points (neither of the tasks have any points in this case).

So my expectation is that all the information you need to follow "limit is in tasks, not points" should already be pretty reasonably available -- just look at X and Z instead of Y and Z. The counter won't turn red if you go over the limit, but you can see at a glance how many tasks are in the column and what limit has been set.

This use case seems rare: no other installs have expressed interest in it that I can recall, except in the variant sense in this task (1 task = 1 point); and it sounds like it is not used universally at WMF either. This use case also seems reasonably possible already, by using convention and looking at the numbers. Obviously, it would be nice for this use case if we had a flag so the "0" didn't show up and the element turned red when it went over the limit, but these seem like pretty minor inconveniences rather than dealbreakers for this workflow? Am I misunderstanding an aspect of this workflow or request?

@epriestley, I'd like to add a bit of extra support for this request. We used to use the column limit to see when we had too many tasks in a certain column. Since the switch to the point limit, we haven't been able to do that.

I work at WMF, on the Analytics team. You're right that this is not universally used at WMF, but it probably should be since it's an effective way to quickly see process bottlenecks. For example:

In Code Review column red: probably not enough time spent reviewing
In Progress column red: probably too much context switching

These conclusions are harder to draw with point limits, because big tasks need to get worked, and sometimes they just cause a column to go red because the whole team can't share one task.

If you pointed us to the code that works on this, we could submit a patch maybe?

Just to be completely sure I understand this:

Since the switch to the point limit, we haven't been able to do that.

You can do this by noticing that X is greater than Z, right? You'd just prefer that the UI turn red too? Or am I still misunderstanding, and there's some actual information missing beyond the red color?

Implementing this is not technically difficult, I am just very hesitant to implement upstream features which benefit a tiny number of users. Some discussion in T8227. I would not accept a patch to make this change; the issue is the lifetime cost of maintaining a feature which is potentially used by only some users on one install forever, not writing the initial patch.

I have no idea what percentage of phabricator current or future users will be task-count-centric rather than story-point-centric. Speaking generally, the Kanban ideal would use task counts, not points. (As compared to the Scrum and XP ideals, which would use points.)

My point is that measuring by task count is neither pervasive nor super-obscure. It is a standard accepted practice in some methodologies. Not supporting it (well) could dissuade some people from choosing phabricator.

I'm not in a position to say whether the impact would meet your threshold for adding and maintaining the feature. Just that it certainly isn't WMF-specific.

Just to be completely sure I understand this:

Since the switch to the point limit, we haven't been able to do that.

You can do this by noticing that X is greater than Z, right? You'd just prefer that the UI turn red too? Or am I still misunderstanding, and there's some actual information missing beyond the red color?

Not quite. We did setup our board [1] to have Z represent the task limit. But, since our tasks are pointed, and each task is at least 1 point, the limit is always going to be passed. So Y is always going to be greater than Z, even though X is not greater than Z. That means the display is always red. It would be ok if it was the other way around, but that wouldn't make sense.

Implementing this is not technically difficult, I am just very hesitant to implement upstream features which benefit a tiny number of users. Some discussion in T8227. I would not accept a patch to make this change; the issue is the lifetime cost of maintaining a feature which is potentially used by only some users on one install forever, not writing the initial patch.

That makes sense. But I agree with Kevin that the point limit seems a lot less useful than the task limit. They're both useful for different reasons, but having been a scrum master and on agile teams for the past 10 years, I find the task limit more fundamental to the processes I've seen.

Thanks for the consideration either way.

But I agree with Kevin that the point limit seems a lot less useful than the task limit. They're both useful for different reasons, but having been a scrum master and on agile teams for the past 10 years, I find the task limit more fundamental to the processes I've seen.

The "strong form" of WIP limit is presumably the column changing color, because this is something that will interrupt you and force you to notice the WIP limit even if you weren't thinking about it. The "weak form" of WIP limit, showing the numbers at the top, doesn't serve the interruptive function well, because unless you are looking for it, you won't see it. And because (X | Y / Z) demands extra effort to remember which is which, what they mean, and what the units are.

Therefore, a number-based strong WIP limit seems more useful to more people than point-based. The main use for point-based WIP limit in Scrum is during Team Planning, but that number usually changes sprint to sprint, and since that number is a focus of Team Planning the weak form of WIP limit is adequate there. So the best possible use of the strong WIP limit would depend on how many Kanban teams out there do point-based WIP instead of count-based, and the Kanban people seem to think count is the majority.

I agree with Kevin that the point limit seems a lot less useful than the task limit. They're both useful for different reasons, but having been a scrum master and on agile teams for the past 10 years, I find the task limit more fundamental to the processes I've seen.

The "strong form" of WIP limit is presumably the column changing color, because this is something that will interrupt you and force you to notice the WIP limit even if you weren't thinking about it. The "weak form" of WIP limit, showing the numbers at the top, doesn't serve the interruptive function well, because unless you are looking for it, you won't see it. And because (X | Y / Z) demands extra effort to remember which is which, what they mean, and what the units are.

Therefore, a number-based strong WIP limit seems more useful to more people than point-based.

Speaking generally, the Kanban ideal would use task counts, not points. (As compared to the Scrum and XP ideals, which would use points.)

My point is that measuring by task count is neither pervasive nor super-obscure. It is a standard accepted practice in some methodologies.

I have little to add, but wanted to throw in my +1 to the above. :)

It may seem like a small impact, but it can have a big affect on teams that rely on traditional WIP. Thanks for your attention.

Thanks, @ksmith @milimetric @jaufrecht @mbinder! +1 to all of you

The Kanban workflow emphasizes limiting WIP which it does by setting task count limits. These limits inform not only that state (=column) of work but also when work can be pulled into the next state as capacity becomes available there. The idea is to reduce variability in flow through the system as well as align WIP with capacity.

In any event, thanks for your consideration.

ivo added a subscriber: ivo.Aug 6 2016, 5:10 PM
aklapper moved this task from Future to Backlog on the Feature Request board.Dec 16 2016, 10:37 AM
pasik added a subscriber: pasik.May 12 2018, 2:00 PM

Bumping this just to say that another team I work with wants to track WIP using count instead of points. In their case, they are a support team, so their board is populated by cross-tagging tasks that belong to other teams. When those cross-tag tasks have story points for the team that originated the task, the story points show on the support team, as well. This means that the support team can't default the story points to 1 just to get the count in WIP.

Anyway, not much more to add to the other existing comments, just wanted to provide another use-case. :)