Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Overlapping sprints 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 via '3rd' parties at the client's site, again, due to policy.

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?

  1. 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.

  2. 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?

  3. 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.

  4. 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.

  5. What else am I missing? What else could or will bite us?

share|improve this question
add comment

4 Answers

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.

share|improve this answer
    
While I agree with the points above the schedule of events, particularly acceptance 1, 2, and production promotions is outside of our teams control. This is determined by client policy. We are unable to remove this overlap. I am looking for ways to better track our progress within these constraints. I have updated my question to reflect this. –  Ryan Taylor May 25 '13 at 23:49
2  
@RyanTaylor Agile is about customer collaboration. If you are unable to discuss with your customer possible change in this process, then I would question using agile at all. –  Euphoric May 26 '13 at 7:09
    
@RyanTaylor You are able to remove the overlap. You just need to do what every business-person hates to see: idle waiting. This will definitely get your problem solved, one way or the other. –  Patrick Jun 8 '13 at 23:25
add comment

The Sprint is an idea 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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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