Project Administration - HenrikBechmann/CivicTechTO-TorontoBudget GitHub Wiki

Methodology

See scrum methodology

Roles

Roles can be shared.

  • Product owner: (to be determined) person(s) with vision, authority, and availability. The Product Owner is responsible for continuously communicating the vision and priorities to the development team

  • Scrum master: Henrik Bechmann The Scrum Master acts as a facilitator for the Product Owner and the team. The Scrum Master does not manage the team. The Scrum Master works to remove any impediments that are obstructing the team from achieving its sprint goals.

  • Team: (roles to be determined) The development team is responsible for self organizing to complete work. A Scrum development team contains about seven fully dedicated members (officially 3-9), ideally in one team room protected from outside distractions. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designer

Sprints

  • Sprints: scope of work that can be accomplished in a relatively brief period (about 10 days of work - about two months elapsed time in this environment - length of each sprint determined by team). Each sprint, the team is responsible for determining how it will accomplish the work to be completed. The team has autonomy and responsibility to meet the goals of the sprint.

Meetings

Each Tuesday meeting will begin with a "standup", no more than 15 minutes, where everyone states what they've done, what their blockers are, what they're planning, and what they need.

Subsequent meeting time will consist of discussion of issues, or collaborative worktime.

Tasks

Classification

Tasks will be tracked in the github project issue tracker.

Each task will be assigned to one milestone:

  • Project selection 2015
  • BACKLOG - tasks not assigned to any other milestone
  • Sprint milestone - sprints are numbered, beginning with sprint 0 for project planning and organization, and are strictly time-limited. Any unfinished tasks are relegated to the backlog or forwarded to the next sprint.

Each task will be assigned to one collaborator, who can share the task with other collaborators (keep track of this in task description or comments). The assignee is responsible for maintaining forward motion for the task. Tasks can be re-assigned for QA, so the original assignee should be recorded in the description.

Each task should have one or more labels:

  • task label: enhancement, bug, etc.
  • Status label: NOT STARTED, IN PROGRESS, BLOCKED, or QA
  • Type label: STORY, SCENARIO, TASK

Stories and Scenarios are product features; Tasks are supporting infrastructure tasks

When a task is done, it is closed. Done means passing QA testing.

Structure

STORY and SCENARIO tasks are structured by the Behaviour Driven Development Gherkin language.

STORY:

As a <role>
I want/need to <take an action>
In order to <achieve a goal>

SCENARIO: (measurable assertions)

Given ... 
When ...
Then ...
And ...

Scenarios are implementations of stories (use cases), therefore scenarios should ideally be referenced inside story descriptions, and stories referenced inside scenario descriptions.

⚠️ **GitHub.com Fallback** ⚠️