We do have our Sprint Review tomorrow. We will not meet our commitment. Bummer.
What happened?
After the planning we did the breakdown of almost all stories. We had 5 Stories and another epic. As we did the epic breakdown we knew that we could not nail down every task since it was clear that some refactoring along the user story would be needed. So we marked one card in that story to remind us that we need to break things further down and refine the tasks.
The first couple of stories went very well (although we still suffer from estimating small stories too big and big stories too small). In the third week we got to our reminder card and our domain experts began to really think about the tasks needed and designed a much more useable and better architecture. This took a couple of hours and could not have been done at breakdown time (or could it?). It turned out it was quite some work to be done but we still could meet the deadline.
Some of us started to implement the new design and things seemed well. What we not did is a detailed planning of the tasks. It was more like we do see what is needed and write down task cards as we see the need for it. This was mostly done on ‘unplanned task cards’ (see earlier post on Scrumboard Cheat Sheet).
Due to the complexity that team could not check in their changes for some days (Remember? Never check in code which does not pass all tests). The only problem was that without that part of code most members of the team could not proceed very effectively on the epic. We found ourselves in a classic deadlock. I was part of those who could not work as intensive on the sprint goal as they would have liked to. It was a frustrating experience. In the end I think we could have been somewhat closer to the goal if we would have seen the warning signs like we just do write the task cards at the stand up (and acting on them). This goes down in my book under ‘Lessons learned’.
I’m not sure how we could have made it better. Doing a better task planning at the breakdown? We usually spent about two hours to define the tasks. Going over that time with the whole team seemed always to stress this a bit and it got less effective .
Should we have spent earlier on more time in designing the refactoring? Two people could have started right after that on that topic. But that epic had a lower priority and everything else should have been done before that if we do follow agile ideas.
However since our Product Owners saw that coming (there were usually at our daily standup) there were not shocked about it as they would have never heard of that problem before. But I guess they are not too happy with us.
Three more days and we are done. Promised.
9 Responses to “Why our current Sprint commitment will fail.”
Leave a Reply
Additional comments powered by BackType
What said the ScrumMaster about that? I’m not programming expert but for me it seems that the issue is in the architecture and not in the management way. How come that one team waits for another? Interface issues? We facing same stuff while waiting for tables (simplify SAP BW terminology) to be created / loaded, but there is always sth. else to do.
Our Scrum Master was unavailable for a couple of days due to some other plannings/reviews. Sure it is the architecture but how do you solve those kind of problems? We needed to do this refactoring. It was not the case that others had nothing to do, just not sprint related, the epic itself was the last task.
I’m a peer of Olli. I think we missed to address this epic early enough. Even if the priority is lower than other stories, it might be a good idea to invest the design session to get a better understanding of what needs to be done. After that, the task breakdown might be more valuable.
What do you think about defining all tasks of all committed stories in the first sprint week (we have 4 weeks iterations)
by the way, how is it possible to set the avatar?
Yes, I guess we need to make sure that we do not have a stories where we know a much more detailed breakdown and/or design is needed. Theses things need to be addressed asap (read: not in the 3rd week).
For the avatar, register an email address with gravatar.com and upload a picture. Many blogs and sites such as any wordpress installation uses gravatar.com to fetch the picture (if you use your registered email address of course).
@Olli: No clue. In SAP BW we are (currently) able to do any kind of agile development, like buidl stuff or automated testing. So I (in my role as Product Owner) would try to detect such things in the planing game (right term? not sure). Tasks for the high priority stories, and additional task for general design with high priority, even if not directly related to a user story.
Currently we need to optimize a complex data model but keep existing reporting up an running. Additional we are bound to volume issues of the database (not another Terrabyte allowed). I’m wondering how to do this, and proper sprints might not be possible under this circumstances, but … Not sure, I think I would set up a well stuffed design “story” and detailed tasks on it. IMHO
PS: My avatar comes through wordpress blog. Follow the link …
Erm, not able, we are not able to develop agile. Sorry!
@Rayk We had once a refactoring sprint/task. We told the PO what and why we need to do things and how long we think it will take. The story which came out was something like: Do the XYZ refactoring (if I remember things correctly).
I thought about the issue after posting my comment. I think that it is possible to put a real user story behind, even if it is a more or less genric one: “Save me 50% money”. The idea could be to “change” the existing soulution (by refactoring or parallel processing or sth. else). So, one may have acceptance criteria (money saved, or will be saved next year) and the team has a goal and could derive tasks from it. IMO there is no need to refactor only because IT people would like to.