I have a team of developers participating in two week Scrum sprints. We track our sprint progress (code pushes to QA region, bug-fixes, prod-support) in Jira. The team also participates in monthly release management activities such as code pre-prod/staging and prod deployment and validations. Typically, the release takes between 6-8 hours (1 story point is 6 hours).

The sprints don't necessarily coincide with release schedules, so to give credit to the developers' release efforts, would it be a good idea to add release related stories on a separate Kanban Board? Is there a better alternative?

  • 5
    What is the impact you are looking to have. You mention giving credit and points == hours, which would insinuate that perhaps the org is judging people's work based on what's on the board, which is an pretty big anti-pattern, but I wanted to check before assuming. – Daniel Feb 8 at 23:03

The purpose of a board is not to give credit to developers. The purpose of a board, especially a Kanban board, is to visualize the workflow.

In this particular case, I see a few possibilities. However, without a full understanding of your workflow, I'm not sure that I can recommend one particular approach.

One approach is to create a "release board" that visualizes the workflow of tasks that go into a release. You can create this board when you start the release process and use it to track all of the validation and release management activities, whether they are unique to a specific release or common across all releases. This type of board would give visibility to stakeholders as to how the release is progressing.

A second approach would be to add the work items to the team's Kanban board for the Sprint. Although the work is not associated with the Sprint, it still happens within the Sprint and affect's the team's capacity. However, the work for release management and validation may have a different workflow that makes this kind of configuration more difficult, depending on the workflow and the board columns.

You can also combine the approaches, with a release board for the detailed work, but a single card (or one card per person on the team) on the Sprint board to denote the people involved in assisting with release management and validation. The visibility into the release work would come from the release board, but it would also make it visible on the team board that people on the team are doing something else that impacts their availability and the team's capacity.

Personally, I would probably favor the first approach of creating a release board and having nothing on the Sprint board. However, if making the team's capacity visible on the team's Sprint board is important, I think the third option is best. I'm hesitant about combining two unrelated workflows on one board and the impact of that on clarity as well as any metrics that you use.

  • +1 on the 1st approach. It's also important to factor in the reduced capacity on sprint for the people looking at the release items. – Tiago Cardoso Feb 9 at 21:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.