Re: [teampractices] Use cases for work tracking, sub-projects, etc in Phabricator
Hi, On Tue, Mar 8, 2016 at 1:02 AM, Joel Aufrecht wrote: > Quim: >> > >> Community Liaisons and Developer Relations have a much simpler process, >> but I still wonder whether we could improve it by using subprojects. >> >> We have team projects to tag any tasks related to our teams, i.e. >> https://phabricator.wikimedia.org/project/view/27/ >> >> Then, we organize what we call monthly sprints but is actually not a >> "Sprint project" but a tag that we add to tasks that we plan to work on a >> certain month, without a commitment to finish them, no story points, no >> burndown. See for instance >> https://phabricator.wikimedia.org/project/view/1649/ >> >> In theory, these monthly sprints could be subprojects of our team >> project, right? If I understood the subprojects feature correctly, this >> would mean that >> >> * Tasks in a sprint (subproject) would not appear in the main project >> (team) workboard, which would be useful to see the tasks that haven't been >> scheduled yet. >> * Tasks in one subproject (i.e. #Liaisons-March-2016) could still be >> added to other subprojects as well (April, May, etc). >> >> Do you think this approach makes sense? >> > > I think that should work as you have described it. Please let us know! > Done: expect that we went for quarterly milestones instead of monthly milestones, in order to align better with quarterly goals: Community Liaisons: https://phabricator.wikimedia.org/project/view/27/ Developer Relations: https://phabricator.wikimedia.org/project/view/33/ Pros: * Milestones appear automatically in the project info page, so they are easier to find even if you don't know they exist. * Milestones appear automatically in the parent project workboard, with their own column, at the right of the columns you have created manually (if any). The header of that column links to the milestone's workboard so, again, user can find them better even when they don't know they exist. * Tasks moved from the parent project to a milestone project are really moved: Herald with remove the task from the parent as it is being added to the milestone. Less duplication and arbitrariety combining parent projects and milestones/sprints. * In the task there is only one tag with a clear description i.e. "Developer-Relations (Apr-Jun-2016)". Again, cleaner and more consistent. Cons: * None found so far? Neutral: * Milestones have a sense of sequence: you create one milestone and then the "next milestone". So far this semantic detail doesn't seem to be used for much, other than sorting milestones in product info pages and workboards. I haven't played with "subprojects" yet. We might have a use case considering i.e. the #Wikimedia-Developer-Summit-2017 a subproject of #Developer-Relations. I wonder how subprojects and milestones play together and with parent projects, but we are in no rush to experiment further, now that we got the new milestones. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Use cases for work tracking, sub-projects, etc in Phabricator
> > Quim: > > Community Liaisons and Developer Relations have a much simpler process, > but I still wonder whether we could improve it by using subprojects. > > We have team projects to tag any tasks related to our teams, i.e. > https://phabricator.wikimedia.org/project/view/27/ > > Then, we organize what we call monthly sprints but is actually not a > "Sprint project" but a tag that we add to tasks that we plan to work on a > certain month, without a commitment to finish them, no story points, no > burndown. See for instance > https://phabricator.wikimedia.org/project/view/1649/ > > In theory, these monthly sprints could be subprojects of our team project, > right? If I understood the subprojects feature correctly, this would mean > that > > * Tasks in a sprint (subproject) would not appear in the main project > (team) workboard, which would be useful to see the tasks that haven't been > scheduled yet. > * Tasks in one subproject (i.e. #Liaisons-March-2016) could still be added > to other subprojects as well (April, May, etc). > > Do you think this approach makes sense? > I think that should work as you have described it. Please let us know! ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Use cases for work tracking, sub-projects, etc in Phabricator
+1 My teams are already using that visibility to stay on top of things better. On Thu, Mar 3, 2016 at 12:03 PM, Joel Aufrecht wrote: > At first I thought that the new Phabricator features didn't help us > significantly with categorization, since sub-projects don't do much > (yet?). However, as Kristen pointed out, the project tags are now visible > on cards, which means that using project tagging is suddenly much more > useful, compared to columns or parent task grouping. > > > > *--Joel Aufrecht* > Team Practices Group > Wikimedia Foundation > > On Wed, Mar 2, 2016 at 1:17 PM, Max Binder wrote: > >> The milestone columning feature, while something I can see providing >> value, doesn't do much for my POs so far. However, there is some interest >> in tagging tasks by feature category, as opposed to parenting under >> sticky-epics, or using a column for each feature. Creating separate tags >> (projects) for apps-specific tasks can make Phab messy overall if there are >> a lot of them, but Milestones might solve this problem by essentially >> existing as project-specific "tags." >> >> On Wed, Mar 2, 2016 at 1:12 PM, Kevin Smith wrote: >> >>> Based on a quick hallway conversation with Joel, I came away feeling >>> like sub-projects probably won't be useful to Discovery. I do still hope to >>> experiment with them at some point, though. >>> >>> On the other hand, hearing that milestone tasks appear in as a column in >>> the parent task's board is quite intriguing. I'll have to check with our >>> POs to see if that would be useful. >>> >>> We are contemplating restructuring the Discovery projects and boards, so >>> this is nice timing. >>> >>> >>> >>> Kevin Smith >>> Agile Coach, Wikimedia Foundation >>> >>> >>> On Wed, Mar 2, 2016 at 12:48 AM, Quim Gil wrote: >>> Hi, On Tue, Mar 1, 2016 at 12:08 AM, Joel Aufrecht >>> > wrote: > > I'm trying to work out, on behalf of VE, exactly how we would want to > use the new sub-project and milestone functionality. > Community Liaisons and Developer Relations have a much simpler process, but I still wonder whether we could improve it by using subprojects. We have team projects to tag any tasks related to our teams, i.e. https://phabricator.wikimedia.org/project/view/27/ Then, we organize what we call monthly sprints but is actually not a "Sprint project" but a tag that we add to tasks that we plan to work on a certain month, without a commitment to finish them, no story points, no burndown. See for instance https://phabricator.wikimedia.org/project/view/1649/ In theory, these monthly sprints could be subprojects of our team project, right? If I understood the subprojects feature correctly, this would mean that * Tasks in a sprint (subproject) would not appear in the main project (team) workboard, which would be useful to see the tasks that haven't been scheduled yet. * Tasks in one subproject (i.e. #Liaisons-March-2016) could still be added to other subprojects as well (April, May, etc). Do you think this approach makes sense? -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices >>> >>> ___ >>> teampractices mailing list >>> teampractices@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/teampractices >>> >>> >> >> ___ >> teampractices mailing list >> teampractices@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/teampractices >> >> > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > > ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Use cases for work tracking, sub-projects, etc in Phabricator
At first I thought that the new Phabricator features didn't help us significantly with categorization, since sub-projects don't do much (yet?). However, as Kristen pointed out, the project tags are now visible on cards, which means that using project tagging is suddenly much more useful, compared to columns or parent task grouping. *--Joel Aufrecht* Team Practices Group Wikimedia Foundation On Wed, Mar 2, 2016 at 1:17 PM, Max Binder wrote: > The milestone columning feature, while something I can see providing > value, doesn't do much for my POs so far. However, there is some interest > in tagging tasks by feature category, as opposed to parenting under > sticky-epics, or using a column for each feature. Creating separate tags > (projects) for apps-specific tasks can make Phab messy overall if there are > a lot of them, but Milestones might solve this problem by essentially > existing as project-specific "tags." > > On Wed, Mar 2, 2016 at 1:12 PM, Kevin Smith wrote: > >> Based on a quick hallway conversation with Joel, I came away feeling like >> sub-projects probably won't be useful to Discovery. I do still hope to >> experiment with them at some point, though. >> >> On the other hand, hearing that milestone tasks appear in as a column in >> the parent task's board is quite intriguing. I'll have to check with our >> POs to see if that would be useful. >> >> We are contemplating restructuring the Discovery projects and boards, so >> this is nice timing. >> >> >> >> Kevin Smith >> Agile Coach, Wikimedia Foundation >> >> >> On Wed, Mar 2, 2016 at 12:48 AM, Quim Gil wrote: >> >>> Hi, >>> >>> On Tue, Mar 1, 2016 at 12:08 AM, Joel Aufrecht >>> wrote: I'm trying to work out, on behalf of VE, exactly how we would want to use the new sub-project and milestone functionality. >>> >>> Community Liaisons and Developer Relations have a much simpler process, >>> but I still wonder whether we could improve it by using subprojects. >>> >>> We have team projects to tag any tasks related to our teams, i.e. >>> https://phabricator.wikimedia.org/project/view/27/ >>> >>> Then, we organize what we call monthly sprints but is actually not a >>> "Sprint project" but a tag that we add to tasks that we plan to work on a >>> certain month, without a commitment to finish them, no story points, no >>> burndown. See for instance >>> https://phabricator.wikimedia.org/project/view/1649/ >>> >>> In theory, these monthly sprints could be subprojects of our team >>> project, right? If I understood the subprojects feature correctly, this >>> would mean that >>> >>> * Tasks in a sprint (subproject) would not appear in the main project >>> (team) workboard, which would be useful to see the tasks that haven't been >>> scheduled yet. >>> * Tasks in one subproject (i.e. #Liaisons-March-2016) could still be >>> added to other subprojects as well (April, May, etc). >>> >>> Do you think this approach makes sense? >>> >>> -- >>> Quim Gil >>> Engineering Community Manager @ Wikimedia Foundation >>> http://www.mediawiki.org/wiki/User:Qgil >>> >>> ___ >>> teampractices mailing list >>> teampractices@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/teampractices >>> >>> >> >> ___ >> teampractices mailing list >> teampractices@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/teampractices >> >> > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > > ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Use cases for work tracking, sub-projects, etc in Phabricator
The milestone columning feature, while something I can see providing value, doesn't do much for my POs so far. However, there is some interest in tagging tasks by feature category, as opposed to parenting under sticky-epics, or using a column for each feature. Creating separate tags (projects) for apps-specific tasks can make Phab messy overall if there are a lot of them, but Milestones might solve this problem by essentially existing as project-specific "tags." On Wed, Mar 2, 2016 at 1:12 PM, Kevin Smith wrote: > Based on a quick hallway conversation with Joel, I came away feeling like > sub-projects probably won't be useful to Discovery. I do still hope to > experiment with them at some point, though. > > On the other hand, hearing that milestone tasks appear in as a column in > the parent task's board is quite intriguing. I'll have to check with our > POs to see if that would be useful. > > We are contemplating restructuring the Discovery projects and boards, so > this is nice timing. > > > > Kevin Smith > Agile Coach, Wikimedia Foundation > > > On Wed, Mar 2, 2016 at 12:48 AM, Quim Gil wrote: > >> Hi, >> >> On Tue, Mar 1, 2016 at 12:08 AM, Joel Aufrecht >> wrote: >>> >>> I'm trying to work out, on behalf of VE, exactly how we would want to >>> use the new sub-project and milestone functionality. >>> >> >> Community Liaisons and Developer Relations have a much simpler process, >> but I still wonder whether we could improve it by using subprojects. >> >> We have team projects to tag any tasks related to our teams, i.e. >> https://phabricator.wikimedia.org/project/view/27/ >> >> Then, we organize what we call monthly sprints but is actually not a >> "Sprint project" but a tag that we add to tasks that we plan to work on a >> certain month, without a commitment to finish them, no story points, no >> burndown. See for instance >> https://phabricator.wikimedia.org/project/view/1649/ >> >> In theory, these monthly sprints could be subprojects of our team >> project, right? If I understood the subprojects feature correctly, this >> would mean that >> >> * Tasks in a sprint (subproject) would not appear in the main project >> (team) workboard, which would be useful to see the tasks that haven't been >> scheduled yet. >> * Tasks in one subproject (i.e. #Liaisons-March-2016) could still be >> added to other subprojects as well (April, May, etc). >> >> Do you think this approach makes sense? >> >> -- >> Quim Gil >> Engineering Community Manager @ Wikimedia Foundation >> http://www.mediawiki.org/wiki/User:Qgil >> >> ___ >> teampractices mailing list >> teampractices@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/teampractices >> >> > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > > ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Use cases for work tracking, sub-projects, etc in Phabricator
Based on a quick hallway conversation with Joel, I came away feeling like sub-projects probably won't be useful to Discovery. I do still hope to experiment with them at some point, though. On the other hand, hearing that milestone tasks appear in as a column in the parent task's board is quite intriguing. I'll have to check with our POs to see if that would be useful. We are contemplating restructuring the Discovery projects and boards, so this is nice timing. Kevin Smith Agile Coach, Wikimedia Foundation On Wed, Mar 2, 2016 at 12:48 AM, Quim Gil wrote: > Hi, > > On Tue, Mar 1, 2016 at 12:08 AM, Joel Aufrecht > wrote: >> >> I'm trying to work out, on behalf of VE, exactly how we would want to use >> the new sub-project and milestone functionality. >> > > Community Liaisons and Developer Relations have a much simpler process, > but I still wonder whether we could improve it by using subprojects. > > We have team projects to tag any tasks related to our teams, i.e. > https://phabricator.wikimedia.org/project/view/27/ > > Then, we organize what we call monthly sprints but is actually not a > "Sprint project" but a tag that we add to tasks that we plan to work on a > certain month, without a commitment to finish them, no story points, no > burndown. See for instance > https://phabricator.wikimedia.org/project/view/1649/ > > In theory, these monthly sprints could be subprojects of our team project, > right? If I understood the subprojects feature correctly, this would mean > that > > * Tasks in a sprint (subproject) would not appear in the main project > (team) workboard, which would be useful to see the tasks that haven't been > scheduled yet. > * Tasks in one subproject (i.e. #Liaisons-March-2016) could still be added > to other subprojects as well (April, May, etc). > > Do you think this approach makes sense? > > -- > Quim Gil > Engineering Community Manager @ Wikimedia Foundation > http://www.mediawiki.org/wiki/User:Qgil > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > > ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Use cases for work tracking, sub-projects, etc in Phabricator
Hi, On Tue, Mar 1, 2016 at 12:08 AM, Joel Aufrecht wrote: > > I'm trying to work out, on behalf of VE, exactly how we would want to use > the new sub-project and milestone functionality. > Community Liaisons and Developer Relations have a much simpler process, but I still wonder whether we could improve it by using subprojects. We have team projects to tag any tasks related to our teams, i.e. https://phabricator.wikimedia.org/project/view/27/ Then, we organize what we call monthly sprints but is actually not a "Sprint project" but a tag that we add to tasks that we plan to work on a certain month, without a commitment to finish them, no story points, no burndown. See for instance https://phabricator.wikimedia.org/project/view/1649/ In theory, these monthly sprints could be subprojects of our team project, right? If I understood the subprojects feature correctly, this would mean that * Tasks in a sprint (subproject) would not appear in the main project (team) workboard, which would be useful to see the tasks that haven't been scheduled yet. * Tasks in one subproject (i.e. #Liaisons-March-2016) could still be added to other subprojects as well (April, May, etc). Do you think this approach makes sense? -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Use cases for work tracking, sub-projects, etc in Phabricator
> > >>- Parenting is too cumbersome because it's not bidirectional. >> >> What exactly do you mean here? I can think of: > Basically what you laid out. As tasks are created, there are far more instances of "this is a child of X" than there are "X should be broken down into Y." It's too hard to add a task to a parent. I suppose that can be a process issue, where one is thinking up new things and fitting them into existing parents/epics, and the other is breaking down an existing epic, but in my experience the teams are more likely to come up with new ideas and see how they fit. Frankly, that feels a little more "planning" rather than "plan" anyway. What would make tagging (categorizing) less lossy? The main thing coming > to mind it to easily see untagged things, in order to create a feedback > loop where you can instantly see what's still untagged and tag it. How > would that work? I think the new board UI helps with this, by showing project tags on cards, but if there are a lot of cards it's still not easy. The primary motivation for getting a product owner to tag is the disarray they will feel if something is not tagged. Additionally, if you want a parent to have a tag, but not the child (such as with the "Milestone" project), you have to manually fix that, and I've observed that most people forget. Phlogiston has mitigated this, some, by showing that if you don't follow process then you won't get your reports. On Tue, Mar 1, 2016 at 11:43 AM, Joel Aufrecht wrote: > On Tue, Mar 1, 2016 at 10:09 AM, Max Binder wrote: > >> I think the appeal of Subprojects is that they offer a new alternative to >> the clunky UI that Phab offers for tagging/parenting/columning. What I'd >> love to see is what "clunk" is relieved and, inevitably, what clunk is >> added. Ultimately, my main issue is that all the ways we've identified, for >> tracking tasks in Phab, are lossy. All the options for organizing work >> after the fact, but are not terribly approachable (and thus not terribly >> sustainable). >> >>- Parenting is too cumbersome because it's not bidirectional. >> >> What exactly do you mean here? I can think of: > >- From a child, it should be possible to choose the parent. > - Currently, this relationship can only be constructed by opening > the parent, entering the child's name in a search function, and > selecting > it from a list. > - It would be an improvement simply to be able to type in child IDs > somewhere on the parent (since that's easier than the name search thing > if > you have the ID handy), but actually better would be to open the child, > click "Add Blocks", and pick titles (or IDs) >- Data model and UI that differentiates between child/parent terms and >blocked by/blocks. > - Enforcement of acyclic directed trees for parent-child >- While looking at a task, see the parent or parents (in the detail, >or on the card, or in a tooltip for the card). > > >>- Tagging is lossy because it's too easy to forget to do it, and >>sometimes the wrong default tags are applied by default (such as when >>creating a subtask). >> >> What would make tagging (categorizing) less lossy? The main thing coming > to mind it to easily see untagged things, in order to create a feedback > loop where you can instantly see what's still untagged and tag it. How > would that work? > >> >>- Columns are workable but they cause a loss of priority of tasks >>across columns. >> >> > >> I guess my question/hope for Subprojects is, "Is it easy to use?" >> > It isn't right now, because moving a task from Project to Subproject is no > easier than changing it from Project A to Project B: in both cases you have > to edit the task, choose to change projects, enter a partial name for the > new (sub)project, and select it. There's no way while looking at a project > board to see the subproject tasks, or even to know what the subprojects are > or that there are any -- you have to click the "Subprojects" option in the > left menu. So the only benefit in the UI right now for Subprojects is that > you can filter a search by a project and get back subproject's tasks. > Which is a use case I haven't seen any teams need yet, actually. > > Milestones have more UI functionality: When you create a Milestone, it by > default is presented as a column in its parent project's workboard. so you > can assign tasks to Milestones within a project via drag-and-drop, and you > can see all tasks in all Milestones within a project. If that > functionality were available for Subprojects, that has some immediate uses. > > >> >> > > ___ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > > ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/li
Re: [teampractices] Use cases for work tracking, sub-projects, etc in Phabricator
On Tue, Mar 1, 2016 at 10:09 AM, Max Binder wrote: > I think the appeal of Subprojects is that they offer a new alternative to > the clunky UI that Phab offers for tagging/parenting/columning. What I'd > love to see is what "clunk" is relieved and, inevitably, what clunk is > added. Ultimately, my main issue is that all the ways we've identified, for > tracking tasks in Phab, are lossy. All the options for organizing work > after the fact, but are not terribly approachable (and thus not terribly > sustainable). > >- Parenting is too cumbersome because it's not bidirectional. > > What exactly do you mean here? I can think of: - From a child, it should be possible to choose the parent. - Currently, this relationship can only be constructed by opening the parent, entering the child's name in a search function, and selecting it from a list. - It would be an improvement simply to be able to type in child IDs somewhere on the parent (since that's easier than the name search thing if you have the ID handy), but actually better would be to open the child, click "Add Blocks", and pick titles (or IDs) - Data model and UI that differentiates between child/parent terms and blocked by/blocks. - Enforcement of acyclic directed trees for parent-child - While looking at a task, see the parent or parents (in the detail, or on the card, or in a tooltip for the card). >- Tagging is lossy because it's too easy to forget to do it, and >sometimes the wrong default tags are applied by default (such as when >creating a subtask). > > What would make tagging (categorizing) less lossy? The main thing coming to mind it to easily see untagged things, in order to create a feedback loop where you can instantly see what's still untagged and tag it. How would that work? > >- Columns are workable but they cause a loss of priority of tasks >across columns. > > > I guess my question/hope for Subprojects is, "Is it easy to use?" > It isn't right now, because moving a task from Project to Subproject is no easier than changing it from Project A to Project B: in both cases you have to edit the task, choose to change projects, enter a partial name for the new (sub)project, and select it. There's no way while looking at a project board to see the subproject tasks, or even to know what the subprojects are or that there are any -- you have to click the "Subprojects" option in the left menu. So the only benefit in the UI right now for Subprojects is that you can filter a search by a project and get back subproject's tasks. Which is a use case I haven't seen any teams need yet, actually. Milestones have more UI functionality: When you create a Milestone, it by default is presented as a column in its parent project's workboard. so you can assign tasks to Milestones within a project via drag-and-drop, and you can see all tasks in all Milestones within a project. If that functionality were available for Subprojects, that has some immediate uses. > > ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Use cases for work tracking, sub-projects, etc in Phabricator
I think the appeal of Subprojects is that they offer a new alternative to the clunky UI that Phab offers for tagging/parenting/columning. What I'd love to see is what "clunk" is relieved and, inevitably, what clunk is added. Ultimately, my main issue is that all the ways we've identified, for tracking tasks in Phab, are lossy. All the options for organizing work after the fact, but are not terribly approachable (and thus not terribly sustainable). - Parenting is too cumbersome because it's not bidirectional. - Tagging is lossy because it's too easy to forget to do it, and sometimes the wrong default tags are applied by default (such as when creating a subtask). - Columns are workable but they cause a loss of priority of tasks across columns. I guess my question/hope for Subprojects is, "Is it easy to use?" On Mon, Feb 29, 2016 at 3:08 PM, Joel Aufrecht wrote: > Hi, > > I'm trying to work out, on behalf of VE, exactly how we would want to use > the new sub-project and milestone functionality. Without going into a full > requirements analysis, I wanted to try to enumerate key use cases and think > through how they are currently met with Phabricator UI (without > sub-projects), how we could use sub-projects, and what data model or UI > changes might be necessary to improve on current processes. The list below > starts with VE, and I would be excited to see how other teams are doing > these things (or what other use cases are important): > > *Triage* > > *As a Product Owner, I want to categorize and prioritize incoming tasks so > that they can be worked on by the right people at the right time.* > VE does this with a weekly triage meeting in which the Product Owner views > all new tasks in the last week, in order of submission (or reversed), and > triages one at a time. Specifically, the PO looks at tasks in the default > column of the VisualEditor project, edits the Priority field, possibly adds > a comment, and drags the task to a different column. In VE, the columns > represent different > [initiatives/ultra-milestones/goals/tranches/categories] (for example, > "Rich Media" or "Language Support"). > > *Overview (grooming)* > > *As a Product Owner with new priorities, I want to alter the backlog for > my project to reflect new priorities.* > VE does this via the PO adding and renaming columns and moving tasks > between columns on the work board. (All VE work is on a single workboard, > which means it's all in one project.) We have also experimented with using > the "Blocked By" relationship to identify a tree of related tasks, but this > is not visible in Phabricator workboards (nor can ancestor Blocked-By be > seen or sorted or filtered on) and can only be seen in Phlogiston reports. > > > *As a Product Owner with knowledge of work in my project, I want to review > the backlog for my project so that I can see if the backlog is current and > correct compared to reality.* > In VE, this has two parts: First, are tasks in right categories? This > normally happens in triage, but the Product Owner occasionally notices > something out of place (a task in the wrong column) while examining the > board view for other purposes. Second, are categories right in relation to > one another? This happens when the PO looks at the board, but more often > when the PO looks at the Phlogiston report that shows not only columns but > also task family (blocked by)-based categorizations. > > VE sometimes does overall work planning (in the style of Scrum card > mapping, where tasks from different areas/columns are all sliced into > different releases/rows) from the board. I've already heard that some > teams have approximated Scrum card mapping by using "dummy tasks" in > columns, so that tasks above or below that task in a column can be > perceived to be in a theoretical "row" that may be consistent across > columns. > > The main activity in VE that isn't supported adequately in Phabricator is > mixing blocked-by relationships and columns. For example, VE may have 50 > tasks in the "Language" column, and five of those tasks may all be set to > block a "Release Korean support". Those six tasks comprise "sub-category" > within Language, where Language is a broad, long-term grouping and "Release > Korean support" is a subset with a fixed scope. There is no way directly > in Phabricator to see, in one view, which tasks share the same blocking > relationship. One way to support this in Phabrictor would be to add a > display field in the task and/or task card showing the ancestor "blocks" > task(s). Currently we can see this in aggregate, but not per-task, in > Phlogiston reports. The sub-project construct supports the same underlying > data relationship, but in a different, reversed way: in Phabricator, you > can filter on a project and you will see all tasks belonging to > sub-projects. > > *Decide what to work on next* > *As someone doing work in a project, I want to use category and priority > a
[teampractices] Use cases for work tracking, sub-projects, etc in Phabricator
Hi, I'm trying to work out, on behalf of VE, exactly how we would want to use the new sub-project and milestone functionality. Without going into a full requirements analysis, I wanted to try to enumerate key use cases and think through how they are currently met with Phabricator UI (without sub-projects), how we could use sub-projects, and what data model or UI changes might be necessary to improve on current processes. The list below starts with VE, and I would be excited to see how other teams are doing these things (or what other use cases are important): *Triage* *As a Product Owner, I want to categorize and prioritize incoming tasks so that they can be worked on by the right people at the right time.* VE does this with a weekly triage meeting in which the Product Owner views all new tasks in the last week, in order of submission (or reversed), and triages one at a time. Specifically, the PO looks at tasks in the default column of the VisualEditor project, edits the Priority field, possibly adds a comment, and drags the task to a different column. In VE, the columns represent different [initiatives/ultra-milestones/goals/tranches/categories] (for example, "Rich Media" or "Language Support"). *Overview (grooming)* *As a Product Owner with new priorities, I want to alter the backlog for my project to reflect new priorities.* VE does this via the PO adding and renaming columns and moving tasks between columns on the work board. (All VE work is on a single workboard, which means it's all in one project.) We have also experimented with using the "Blocked By" relationship to identify a tree of related tasks, but this is not visible in Phabricator workboards (nor can ancestor Blocked-By be seen or sorted or filtered on) and can only be seen in Phlogiston reports. *As a Product Owner with knowledge of work in my project, I want to review the backlog for my project so that I can see if the backlog is current and correct compared to reality.* In VE, this has two parts: First, are tasks in right categories? This normally happens in triage, but the Product Owner occasionally notices something out of place (a task in the wrong column) while examining the board view for other purposes. Second, are categories right in relation to one another? This happens when the PO looks at the board, but more often when the PO looks at the Phlogiston report that shows not only columns but also task family (blocked by)-based categorizations. VE sometimes does overall work planning (in the style of Scrum card mapping, where tasks from different areas/columns are all sliced into different releases/rows) from the board. I've already heard that some teams have approximated Scrum card mapping by using "dummy tasks" in columns, so that tasks above or below that task in a column can be perceived to be in a theoretical "row" that may be consistent across columns. The main activity in VE that isn't supported adequately in Phabricator is mixing blocked-by relationships and columns. For example, VE may have 50 tasks in the "Language" column, and five of those tasks may all be set to block a "Release Korean support". Those six tasks comprise "sub-category" within Language, where Language is a broad, long-term grouping and "Release Korean support" is a subset with a fixed scope. There is no way directly in Phabricator to see, in one view, which tasks share the same blocking relationship. One way to support this in Phabrictor would be to add a display field in the task and/or task card showing the ancestor "blocks" task(s). Currently we can see this in aggregate, but not per-task, in Phlogiston reports. The sub-project construct supports the same underlying data relationship, but in a different, reversed way: in Phabricator, you can filter on a project and you will see all tasks belonging to sub-projects. *Decide what to work on next* *As someone doing work in a project, I want to use category and priority and assignment information to figure out which task to work on next.* Normally, VE team members do this via consultation with the Product Owner, but on occasion they navigate to the VE work board and look at the top of the columns they are working on to identify new work. *Definitions* "Category" refers to fields differentiating the type of work or subject of the work (which software package, which team, which website, etc) that people use to filter tasks. I've seen teams use project tags, project columns, blocked by relationships, and tacit conventions about task placement within Phabricator project boards, and combinations thereof, to categorize work. "Priority" refers to any task information used to determine relative importance; I'm aware of teams using either the Priority field, or position and rank within a Phabricator project or columns, or both. *--Joel Aufrecht* Team Practices Group Wikimedia Foundation ___ teampractices mailing list teampractices@lists.wiki
