- User Since
- Aug 5 2016, 10:14 PM (284 w, 5 d)
May 28 2020
Bumping again simply because this has come up a few times this month. Teams I work with want to use a WIP feature, but don't use the current implementation because it tracks points instead of tasks. Reviewing the rest of the comments in this thread, all of it remains relevant to those use-cases.
Mar 12 2019
Jul 19 2018
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.
Oct 20 2016
my current view is basically that the official subprojects implementation only makes this much more clunky and restricts some parts of it, rather than moves it forward. As it is, the current subproject implementation doesn't seem to do much else than make a couple of links appear, and restrict the usage of some features (tagging and project membership handling are changed/restricted, at least).
Oct 10 2016
Sep 29 2016
@epriestley Yup, thanks, will do. I only meant to see if one was necessary, but I was not clear with that ask. :)
I'm late to this party, so please forgive me for reanimating an old discussion.
Aug 5 2016
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.