Pivotal Task Tracker: Difference between revisions

From Open Source Ecology
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
*User story - a request; who is requesting something and why
* User story - a request; who is requesting something and why
*story - a deliverable; specific request
* story - a deliverable; specific request
*Task - is specific. User story is more abstract, allows more flexibility to person doing the action. Point: specific is good. It allows direct results to be produced for the project. This limits contributions to significant ones only.
* Task - is specific. User story is more abstract, allows more flexibility to person doing the action. Point: specific is good. It allows direct results to be produced for the project. This limits contributions to significant ones only.


 
= Abstract =
=Abstract=


Right now with GVCS Development we have the wonderful pickle of having many assistance offers, but many of them are not aligned with our core mission. This ends up wasting organizational time on part of the core GVCS development team. To address this, we are pursuing a task tracking system which by design - or automatically - puts people on the right track.
Right now with GVCS Development we have the wonderful pickle of having many assistance offers, but many of them are not aligned with our core mission. This ends up wasting organizational time on part of the core GVCS development team. To address this, we are pursuing a task tracking system which by design - or automatically - puts people on the right track.
Line 10: Line 9:
Properties of Tracker:
Properties of Tracker:


*Low entry barrier to participation
* Low entry barrier to participation
*Infinite spawnability of new projects
* Infinite spawnability of new projects
*By invite only
* By invite only


= Metalevel Description of Pivotal Functionality =


=Metalevel Description of Pivotal Functionality=
* Someone creates a project
 
* 5-10 people per project - or too many people trying to work together; at best, small team, collocated, with high level of trust
*Someone creates a project
* Task list is created (Icebox). These are the user stories or requests as defined above.
*5-10 people per project - or too many people trying to work together; at best, small team, collocated, with high level of trust
* Someone takes on task, rates its difficulty on a relative scale, and then it can be started.
*Task list is created (Icebox). These are the user stories or requests as defined above.
* Reasons for using a Tracker:
*Someone takes on task, rates its difficulty on a relative scale, and then it can be started.
** Provides transparency:
*Reasons for using a Tracker:
*** Tasks to be done
**Provides transparency:
*** If anyone is doing a task
***Tasks to be done
*** What the status is (not taken, in development, delivered, or complete
***If anyone is doing a task
** Prioritizing all tasks (in backlog and initial task list)
***What the status is (not taken, in development, delivered, or complete
** Estimation of time to completion (probably not so useful due to a large number of unknown, critical parameters)
**Prioritizing all tasks (in backlog and initial task list)
** Allows stakeholder to make requests and rank them in importance, and allows team members to offer a deliverable on their own schedule; allows team team members' difficulty ratings to influence prioritization by stakeholder
**Estimation of time to completion (probably not so useful due to a large number of unknown, critical parameters)
**Allows stakeholder to make requests and rank them in importance, and allows team members to offer a deliverable on their own schedule; allows team team members' difficulty ratings to influence prioritization by stakeholder


To summarize: this tracker formalizes the basic human interaction pattern of creating shared promises - via request, offer, submission, and acceptance/rejection cycles.
To summarize: this tracker formalizes the basic human interaction pattern of creating shared promises - via request, offer, submission, and acceptance/rejection cycles.


= Populating the Tracker with Tasks =


=Populating the Tracker with Tasks=
* Start with 32 steps of [[GVCS Development Template]]
* Break down the 32 steps into substeps. This is the master index.
* Import into pivotal tracker
* Generate [[Systems Engineering Breakdown Map]]
* Use google map or cMap tools as a breakdown tool and indexical environment for each project.


*Start with 32 steps of [[GVCS Development Template]]
= Useful Tips =
*Break down the 32 steps into substeps. This is the master index.
*Import into pivotal tracker
*Generate [[Systems Engineering Breakdown Map]]
*Use google map or cMap tools as a breakdown tool and indexical environment for each project.
 
 
=Useful Tips=


'''Use Labels'''
'''Use Labels'''
Line 51: Line 47:
* ''drawing'' box
* ''drawing'' box
* ''drawing'' button
* ''drawing'' button
[[Category: Organization]]

Revision as of 06:07, 2 June 2011

  • User story - a request; who is requesting something and why
  • story - a deliverable; specific request
  • Task - is specific. User story is more abstract, allows more flexibility to person doing the action. Point: specific is good. It allows direct results to be produced for the project. This limits contributions to significant ones only.

Abstract

Right now with GVCS Development we have the wonderful pickle of having many assistance offers, but many of them are not aligned with our core mission. This ends up wasting organizational time on part of the core GVCS development team. To address this, we are pursuing a task tracking system which by design - or automatically - puts people on the right track.

Properties of Tracker:

  • Low entry barrier to participation
  • Infinite spawnability of new projects
  • By invite only

Metalevel Description of Pivotal Functionality

  • Someone creates a project
  • 5-10 people per project - or too many people trying to work together; at best, small team, collocated, with high level of trust
  • Task list is created (Icebox). These are the user stories or requests as defined above.
  • Someone takes on task, rates its difficulty on a relative scale, and then it can be started.
  • Reasons for using a Tracker:
    • Provides transparency:
      • Tasks to be done
      • If anyone is doing a task
      • What the status is (not taken, in development, delivered, or complete
    • Prioritizing all tasks (in backlog and initial task list)
    • Estimation of time to completion (probably not so useful due to a large number of unknown, critical parameters)
    • Allows stakeholder to make requests and rank them in importance, and allows team members to offer a deliverable on their own schedule; allows team team members' difficulty ratings to influence prioritization by stakeholder

To summarize: this tracker formalizes the basic human interaction pattern of creating shared promises - via request, offer, submission, and acceptance/rejection cycles.

Populating the Tracker with Tasks

Useful Tips

Use Labels

Create labels that represent sub-tasks. Say for example that your machine has three parts: base, box, and button. Naturally, each of these will need engineering drawings. Create the story with the name of the drawing and give it a label of "drawing". The titles of the stories will then appear as:

  • drawing base
  • drawing box
  • drawing button