Tuesday, 2 June 2015

The 'bouncing spaghetti' burndown

Haven’t seen such a bouncing (up/down) burndown chart for quite a while. And the last sprint for my German team was really ‘interesting’, meaning hectic. We are in the middle of some software qualification activities so the Sprint main goal was a couple of stories related to qualification of different modules.

The chronology of the time events will probably help in understanding what really happened:

The sprint planning (08.May) was well executed and the team committed to a number of stories and a total time of about 150h remaining with only 3 developers and 1 test consultant.

Over the next sprint day additional task was added.

On the 12th of May after the Daily standup we updated the time (most importantly the remaining time values), leading to almost ‘ideal progress’ according to our planning and the ‘average velocity’.

Over the next couple of days the progress was going almost close to the ‘ideal/average velocity’.

Then on 19th May, our test consultant, could not fully contribute to the remaining stories and tasks anymore. So he decided (in agreement with the Product Owner /PO/) to add a new story and a couple of tasks to it. He could not estimate precisely the tasks and put some very big numbers as ‘remaining hours’ pushing the chart up significantly. Some unplanned support requests were also added to the Sprint backlog at that time with high priority.

Over the next 2 days we still logged the proper story time and re-estimated the new tasks remaining time (as it was more obvious what is achievable at that point) but the reduction was not enough and it seemed some of the stories would fail.

On May 22nd our PO came in distress and announced the due date for all the qualification activities has been shifted significantly forward and we need to take more stories for the sprint. He also partially joined the team as a developer to help with the new items. Luckily for us a colleague from another team also fully joined, and another colleague was supposed to partially join to help with the increased work. So the team size happily increased by roughly 2 more developers.

Nevertheless our progress in the next couple of days was slow due to impediments, issues and slow progress for the unplanned work. On May 28th my team in Bulgaria had some extra space and the remaining of one of the stories in the middle of the sprint backlog (‘average priority’) was transferred to them for completion. At that day we calculated the progress and decided on items to kick-out and focus only on the top prio activities resulting in better planning for the next three days. Yes, three days – it was already expected and announced (over the Sprint planning) we are going to work on the last Saturday of the Sprint too.

Finally, in the evening of May 30, the code changes were released successfully and the top stories were completed and approved. The support requests were also successfully delivered. The trade-off was some lower prio items on the bottom of the backlog.

---

A lot of the Scrum-book prescriptions were not followed to allow the team to remain ultra-flexible (e.g. scope freeze in the beginning of the sprint, team size changes during the sprint, transferring stories to another team, re-prioritization during the sprint, adding extra /weekend/ day to the sprint, skipping retrospective /just this time, to allow more time for delivery on the last sprint day/)

No comments:

Post a Comment