Welcome back everyone. I have been busy for the last month working hard trying to achieve a substantial success in this sprint as it had a special value to me; first, because it came after a long time of being idle, and second, because we had just resolved some external issues that held us back in the previous sprints.
At the beginning of the sprint we went through with a high velocity without the need for any overtime nor affecting quality which impressed me and later we had some tasks that required additional efforts than expected so we started losing velocity. We were still inline with the optimal burn-down but not for long.
I was still convinced that the remaining tasks can be squeezed in the final few days of the sprint. So we kept the hard work crossing our fingers to finish on time. Unfortunately, we had to extend the sprint for one day, ignore some features, jeopardize quality, and finally (as expected), the final build was rejected.
It is hard to admit the failure, but the bitterness of failure is the medicine that heals your weaknesses, and our sprint retrospective was really fruitful and full of lessons learned, so here are some:
- Pairing of tasks does not always result in dividing the effort (the famous example: nine women cannot give birth to a baby in one month).
- Instead of pairing, you can divide tasks into smaller ones, which have more benefits; more accurate estimation, a checklist to define what’s is meant by “done”, and less dependency of tasks.
- It is better to be pessimistic in you estimation till your team proves otherwise than to commit to what you are not 100% sure you can achieve.
And my personal lesson I learned was:
- It feels good to be superman, but it feels worse if you fails to prove it.
Let me add one point to your list of lessons learned (from my own experiences).
I’ve never seen a sprint extension pay off. Every time we did it, we spent an extra day getting to that failed point and an extra day before having the retrospective, learning things, and making adjustments.
I don’t have enough details to answer your specific situation, but reflect on whether that day helped more than hurt. Will you do it again?
LikeLike
I totaly agree with you deeb you have to be pessimistic in you estimation , ecpically in the first two or three sprints,or when a new member just joined ;), all these are risk factors that may be ignored during the planning which lead to bad quality or delay
LikeLike
Thanks for sharing your experience.
I’m starting out on agile implemenation for my project; these notes are really useful.
LikeLike