Our team has adopted some agile practices to help us develop and deliver our software to our client. We adopt 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 roughly one month sprints. We do estimate the items in our sprint backlog to guesstimate what we can deliver within a sprint. However we do not track progress very well so it's difficult to know whether or not we are on target.
The next step in our evolution appears to be to 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. That said we do test our software throughout this phase with the development and test groups.
- Code freeze stops development on Sprint 1 functionality. We have a 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.
This schedule of events is not within our control. Client policy dictates when application software is promoted from Test to Acceptance to Production. No application code may be modified beyond our second fix window. We do not perform the promotions. This is accomplished by '3rd' parties at the client's site, again, due to policy.
In addition, some tasks such as data updates, can and do happen outside of this schedule. Certain data updates follow the code (for instance, when there is a schema dependency) but others such as data bugs or new data can and do occur outside of this schedule. This is due to fewer restrictions as to what may be modified on the clients environment and when. 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, our 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 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 to bump out less critical Sprint 2 items to make room for the incomplete Sprint 1 items. Non critical items will be bumped to Sprint 3 or later.
What would be the proper start and end dates for the burn down chart?
It seems the best option would be to reflect reality. Sprint 1 is not truly done (including testing and data updates) until production promotion and its final testing. So the start date would be development begins and the end date be production promotion despite any overlap.
What else am I missing? What else could or will bite us?