5.6 KiB
Agile Working at Ypsomed IT
Communication
For any concerns or clarifications, the Team Lead or Workstream Lead should be consulted. They serve as an enabler and coordinator.
A dedicated channel on Teams will be established for general communication to quickly address questions or blockers.
Tools: MS Teams Channel
Documentation
Everyone must have independent access to documentation, including specifications, decissions, and changes. We aim to work in a decentralized and asynchronous manner. Each individual should always be able to access all necessary information. We see documentation as a joint effort of all members and everybody should always improve documentation as needed. For some guidlines see Documentation Guidlines, these should be rather interpreted as code of conduct than strict rules.
Tools: Azure DevOps Repos and Wikis
Meeting Minutes
Meeting notes are centralized taken as tasks in Azure DevOps. Everybody is responsible for them. If you hear something in a meeting that is relevant for you: add it as a comment during the meeting, after the meeting. The meeting minute tasks don't need a parent. They should follow a template (to be defined) and can be linked to Stories and other work items like Issues (Impediments) which have been discussed during the meeting.
Tools: Azure Boards Task
The PI and sprints
The PI (Product Increment, a term from SAFe) is the time frame in which the team works on a set of features. The PI is typically divided into 5 sprints of two week duration. We alligned our calendar with the business units' PI's and sprints.
Task management kanban setup
We based our setup on the CMMI process template. The following work items and states are used in the team.
- Tasks move from left to right.
- Each team member works on tasks, selected independently from the "Ready" area.
- Tasks in the "Done" column of each state should first undergo a peer review within the team.
- Only tasks in the "Closed" column are considered fully completed.
- It is best practice to not have more than 2 work items in progress at the same time.
Tools: Azure Boards
Epics
Backlog
- Description: High-level requirements or desired outcomes that contain multiple features.
- Definition of Done: Epic is clearly defined with a goal and scope. Value area is set, either IT internal, or external facing e.g. YDS or YDC.
Analysis
- Description: Breakdown and planning phase where epics are split into actual features and maybe already user stories.
- Definition of Done: Dependencies, risks, and initial estimation are identified; epic is broken down at least into features.
Ready for Development
- Description: Epics that have been broken down, and their features or user stories are ready to be worked on.
- Definition of Done: All features or user stories under the epic are defined and prioritized in the backlog. (Besseres Wording für die Rolende Planung, die ersten 2 Features sind vielleicht schon im Detail geplant, die letzten noch nicht.)
In Progress
- Description: Active development and implementation of the features or user stories under the epic.
- Definition of Done: All related features or user stories are in development or completed.
Acceptance
- Description: Evaluation of completed features or stories to ensure they meet the epic's goals.
- Definition of Done: All related features or user stories are reviewed, tested, and accepted by stakeholders. All objectives of the epic are met, and they have a positive impact on the product or service. Stretch goal: lessons learned are documented, assumptions from the beginning are reviewd. It is clear what we can do better in the future.
Closed
- Description: Epics that have achieved their goals and all underlying features or user stories are completed.
Features and Stories
Backlog
- Description: Identified features or stories not yet prioritized or ready for development.
- Definition of Done: Feature or story are defined with acceptance criteria.
Ready for Development
- Description: Prioritized features or stories that are fully defined and ready to be picked up by the development team.
- Definition of Done: All prerequisites are met, and tasks are identified and estimated.
In Development
- Description: Active development of the feature or story.
- Definition of Done: Functionality is implemented or desired outcome e.g. documentation is created, tested and peer-reviewed.
Testing
- Description: Feature or story undergoing testing (could include QA, automated tests, etc.).
- Definition of Done: All tests pass, and any defects are fixed and retested.
Acceptance
- Description: Feature or story is reviewed by stakeholders and/or product owner for acceptance.
- Definition of Done: Acceptance criteria are met, and the feature or story is approved by the product owner.
Closed
- Description: Feature or story is fully implemented, tested, accepted, and ready for release.
For Tasks
Tasks are generally optional and can be used to break down stories into smaller pieces or to track work that is ditributed over multiple team members.
To Do
- Description: Work items that need to be addressed but have not yet been started.
- Definition of Done: Task is defined with clear steps and acceptance criteria.
In Progress
- Description: Tasks currently being worked on.
- Definition of Done: Task is completed as per the acceptance criteria.
Acceptance
- Description: Completed tasks being reviewed for quality and adherence to requirements.
- Definition of Done: Task passes review, meets quality standards, and no further work is required.
Closed
- Description: Tasks that are completed and meet all acceptance criteria.