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.
larger resolution version
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?
1
I don’t think how you have your development setup is good idea. One of the reasons for sprints being bounded and non-overlapping are exact problems you just encountered. I would recommend focusing more on simplifying your sprint cycle than bothering how do make burndown chart.
First 4 weeks is on border of recommended sprint length and along with 2 weeks of “testing” basically makes your whole spring 6 weeks long, which is definitely not normal for agile practice.
Usually customer testing happens during sprint and errors/suggestions based on this testing are taken into account in the next available sprint. The exact reason for having short sprint is to quickly react for problems customer might have with project without need for such complex development/testing process.
Also, you should try thinking about implementing automated acceptance tests with automated deployment into customer’s testing environment. If you have those, you can easily run them in between short time between the sprints. This will probably require much closer collaboration with your customer, what is one of the basics of agile practice.
3
By making code freeze a solid line and only promoting tested code you can eliminate the ambiguity of that two week time frame where sprints overlap. This will however require you to have the testing done sooner and automated testing will allow you to fix a bug and ensure that it stays fixed.
Perhaps adopting a policy that your master branch of development is always ready to be pushed to production and have all testing done prior to committing code to this master branch. If features run over in time or scope simple don’t push them into the master branch.
A burndown chart would be easier to implement given a list of desired features and tasks for a sprint. If at code freeze – 1 week you have 3/5 features pushed to the master you have a clear idea of where you stand. If you wish finer grained control breakdown features into a burndown that aggregates into The master burndown.
1
Another way to look at it, is that your 4-week sprint begins 2 weeks into you diagram, with first 2 weeks of development and another 2 weeks of code freeze etc. idle time in those last two weeks can be used to prepare for the next sprint. But that sprint officially starts 6 weeks into your diagram (after acceptance of the previous sprint).
Not only will this create a clearer priority (getting acceptance is more important than starting on new things), it also allows for a perfectly textbook release burn down.
The simplest way is to stop thinking that Scrum is agile and use a slightly different (and better – everything is better than Scrum 🙂 ) methodology such as Kanban.
You do not need a burndown chart to be agile, and you do not even need to be “on target”. Burndowns are really there solely as a tool to help you determine how much work you should be able to achieve in a sprint, as measured by work completed in previous sprints. Other methodologies do not bother with such things and prefer to just do what is needed until complete – which is what you do in Scrum anyway, but without the pressure of a burndown chart driving you to burnout.
If you insist on using burndown charts, remember that they are tools based on previous work (which is why you use estimation tools like t-shirt sizing for tasks instead of allocating definite time durations), a burndown is a relative to every other burndown. So you can simply set your sprint to include the 6 weeks (yes, ignoring the overlap) as the amount of work you get done in one sprint will be reduced by the overlapping work, and the sprint after that will also include the overlapping work, etc. This means every burndown will be consistent with every other one, and therefore will be self-regulating. After 3 sprints your velocity will settle down to a stable number. (note, in normal Scrum systems you have to perform 3 sprints or so to get a stable velocity anyway!)
The Sprint is an name taken from Scrum. At the end of a Sprint your software should be “potentially shippable”.
During a Sprint your team should be free from interference but committed to delivering the software at the end of the sprint.
What you are doing would not normally be described as a sprint.
It looks like during your 4 week iteration you have a couple of days for bug fixing from the release branch.
You have many options, my preferred choice would be to reduce the iteration length to 1 week long, and when you need to do work on the release branch, introduce that to the appropriate sprint backlog. Issues identified in UAT should be fixed in iteration/week 5. To avoid waste, I would try to line up the start of an iteration with this window for fixes. The acceptance testing should not be considered special compared to any other bug fix. The bugs they discover should just go into the backlog and be prioritised as appropriate.
Alternatively as if it is a relatively fixed amount of work, that is, it always takes a certain numer of days, then I would time box the activities of bug fixing and not consider it as part of the burn down. You need ensure that time taken and pts/estimate are tracked for these issues.
Another option is to put in some placeholder stories for the work that will likely result from the acceptance testing. You can work out the points to assign them by using the amount of effort that they have taken historically.