Follow up on requests
In order to ensure that the issue status remains transparant and that the team is able to deliver on scope and on time (or that this can pro-actively be discussed & handled), we use a dedicated GitHub board to provide all stakeholders with an oversight their full backlog.
This board is a living document and will be updated as issues are moved through the process. Each status on the board containing information to better understand the state of the issue and the actions to be taken.
Let’s look at all of these different statuses and what they mean for you.
Phase 1: Preparing the issue
The first 3 statuses on our board will guide the preparation process in order to prepare everything for implementation during our sprint. This means that there needs to be final clarity and alignment between the Customer Lead (Skyscrapers) and the issue owner (Customer) on timing, scope, budget and priority.
Note
Upon creation the issue is not yet in our sprint backlog. This means that the issue is not part of the sprint backlog yet and will not be delivered until further notice.
Status overview
| Status | Description |
|---|---|
| Incoming | The issue has been logged and is waiting for the team to kickstart determining Worktype, desired delivery date, scope, priority and high level estimate |
| Refinement | The issue does not contain sufficient information yet for implementation. Once assigned to a Skyscrapers team member further refinement of this issue is ongoing in order to clarify the issue for actual implementation. |
| Qualified | The issue is ready to be implemented and is awaiting the next sprint planning in order to be considered for implementation. The Skysrapers team works in weekly sprints and convenes every Friday in order to plan next week’s sprint. |
Phase 2: Implementating the request
The next 3 statuses on our board will guide the actual implementation of the issue during our 1 week sprint. Once the issue is in the sprint backlog, the team is actively working on it and commits to actually deliver on it by the end of the sprint (1 week).
Status overview
| Status | Description |
|---|---|
| Sprint backlog | The item is part of the sprint and the team commits to progrss this item to at least ‘To Clarify’ state as part of this sprint. Preferrably we manage to get all sprint backlog items progressed to ‘Done’, but this is where we will need your help! |
| In progress | The is actively being worked on by our engineers and is being implemented as we speak. |
| To clarify | Implementation has been completed on these items as far as possible. If the work is completed, we will offer it for final validation prior to closing it. If follow up steps (e.g. rollout planning) require additional input from the customer, this is where the issue will await re-activation from you as a customer. Please be aware that - when reactivated, the issue will move back to Refinement or Qualified and not straight into the sprint backlog! |
Phase 3: Closing after completion
The last status on our board takes care actual closure of the issue. This means that it has been implemented completely and no further work will be needed for this issue.
Status overview
| Status | Description |
|---|---|
| Done | The issue is fully resolved and will no longer be worked on. It is kept in the repostiry for documentation & traceability. |