Tracking progress via a burndown chart when sprints overlap
Our team has adopted some agile practices to help us develop and deliver our software to our client. We adopted practices as needed (as problems/challenges were identified) rather than jumping wholesale into the agile camp. The big ones for us are maintaining a product and sprint backlog and developing and delivering new versions in one month sprints. We do estimate the items in our sprint backlog to guesstimate what we can deliver within a sprint however we are not tracking progress very well so its difficult to know whether or not we are on target.
The next step in our evolution appears improve our progress tracking ability. We are looking at using burn down charts to aid us. However, our sprints overlap significantly due to established and procedures for our software promotion schedule. We have the following established events:
Development begins on Sprint 1 and continues until code freeze.
Code freeze stops development on Sprint 1 functionality. We have small window to finish or fix any issues before the next event acceptance promotion 1. In addition development begins on Sprint 2.
Acceptance promotion 1 promotes the application to the client's acceptance environment where it is tested by our test group. Issues identified in testing may be fixed during a small window before acceptance promotion 2. Meanwhile Sprint 2 development continues.
Acceptance promotion 2 promotes the application one last time to the client's acceptance environment to validate any issues identified during acceptance promotion 1. Sprint 2 development continues.
Production promotion promotes the application to production and it is tested by our test group and Sprint 1 is officially completed. This is when it is truly done.
A visual depiction of this can be seen below. The average calendar time between development begins and code freeze is four weeks. The average time between code freeze and production promotion is two weeks.
larger resolution version
In addition some tasks, like such data updates can and do happen outside of this schedule. Some data updates follow the code (for instance, when there is a schema dependency) but others such as data bugs or updates can and do occur outside of this schedule. This is due to fewer restrictions as to what may be modified on the clients environment. Only application code is restricted to these specific milestones. Data and configuration are exempt and technically may be modified as needed. We are considering tightening this up so that data updates follow the same schedule as the code.
Given this scenario, overlapping sprints I have a several questions?
What is the proper way to create/handle a burn down chart when we burn development, testing, and data hours from the previous sprint while working also working towards the next one?
I think we have 2 concurrent burn down charts on for each sprint.
Assuming we at most have two burn down charts how do we best display the cumulative burn down when the sprints overlap so as to understand our actual workload progress on each so as to best set us up for success?
If items are found in Sprint 1 after code freeze that need to be addressed in Sprint 2 how does that our Sprint 2 backlog and burn down?
I assume that for critical items we need
Our team has adopted some agile practices to help us develop and deliver our software to our client. We adopted practices as needed (as problems/challenges were identified) rather than jumping wholesale into the agile camp. The big ones for us are maintaining a product and sprint backlog and developing and delivering new versions in one month sprints. We do estimate the items in our sprint backlog to guesstimate what we can deliver within a sprint however we are not tracking progress very well so its difficult to know whether or not we are on target.
The next step in our evolution appears improve our progress tracking ability. We are looking at using burn down charts to aid us. However, our sprints overlap significantly due to established and procedures for our software promotion schedule. We have the following established events:
Development begins on Sprint 1 and continues until code freeze.
Code freeze stops development on Sprint 1 functionality. We have small window to finish or fix any issues before the next event acceptance promotion 1. In addition development begins on Sprint 2.
Acceptance promotion 1 promotes the application to the client's acceptance environment where it is tested by our test group. Issues identified in testing may be fixed during a small window before acceptance promotion 2. Meanwhile Sprint 2 development continues.
Acceptance promotion 2 promotes the application one last time to the client's acceptance environment to validate any issues identified during acceptance promotion 1. Sprint 2 development continues.
Production promotion promotes the application to production and it is tested by our test group and Sprint 1 is officially completed. This is when it is truly done.
A visual depiction of this can be seen below. The average calendar time between development begins and code freeze is four weeks. The average time between code freeze and production promotion is two weeks.
larger resolution version
In addition some tasks, like such data updates can and do happen outside of this schedule. Some data updates follow the code (for instance, when there is a schema dependency) but others such as data bugs or updates can and do occur outside of this schedule. This is due to fewer restrictions as to what may be modified on the clients environment. Only application code is restricted to these specific milestones. Data and configuration are exempt and technically may be modified as needed. We are considering tightening this up so that data updates follow the same schedule as the code.
Given this scenario, overlapping sprints I have a several questions?
What is the proper way to create/handle a burn down chart when we burn development, testing, and data hours from the previous sprint while working also working towards the next one?
I think we have 2 concurrent burn down charts on for each sprint.
Assuming we at most have two burn down charts how do we best display the cumulative burn down when the sprints overlap so as to understand our actual workload progress on each so as to best set us up for success?
If items are found in Sprint 1 after code freeze that need to be addressed in Sprint 2 how does that our Sprint 2 backlog and burn down?
I assume that for critical items we need
No comments:
Post a Comment