Skip to content

Follow-up Team-Contract: "As a team, we ensure that task priorities are clearly defined by PO. The team is encouraged to give input on visibility, strategy and alignment." #4178

@hannaseithe

Description

@hannaseithe

Background

During our last conference, we agreed on a 9-paragraph team contract.
This issue follows up on Paragraph [#], which states:

“As a team, we ensure that task priorities are clearly defined by PO. The team is encouraged to give input on visibility, strategy and alignment.”

Objective

Clarify what “making this paragraph a reality” means in practice.

The goal of this issue is to:

  • make sure that every team member knows which task (new issue, review, write documentation, research, etc) to pick up next.
  • enable team members to share their view on strategy compatibility by making the overall strategy more visible.

[Any measurable result if applicable]

Scope of Work

Concrete tasks expected:

PO ensures that the direction for the next roadmap is clear so that the team is enabled to select from existing issues and create new issues to fulfill the vision in the roadmap

PO shares direction for the next roadmap ahead of the conference (best 2-3 weeks ahead) so that the team (maybe only team lead) can prepare ideas for discussion at the conference

Backlog column in GitHub Boards are sorted by PO according to priority of issues - always up to date ahead of the team weekly (realistic expectation for this when regarding swimlane backlog is towards the next conference in June)

Pull-Criteria and WIP-Limits are defined to make the next item/task to take up easier to identify (@osmers in charge)

Meeting structures for roadmap and sprint planning are more defined/clear so that make clear prioritization possible (@jarlhengstmengel in charge)

Deliverables

What should exist when this issue is done?

  • a leaner, more organised backlog
  • ideally an always up to date board in GitHub bcs new issues can be immediately sorted

Definition of Done

This issue is complete when:

  • documentation about the processes exists
  • when legacy issues in the CMS repo are cleaned up

Metadata

Metadata

Labels

No labels
No labels

Type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions