Better software through software architecture and devops

@jamessnape

Sprint Review Time

It’s nearly the end of the month and hence end of the current sprint. I was having a discussion with a developer this morning about the amount of work remaining on the list. The developer in question hasn’t been able to spend a lot of time on the project this month due to higher priority customer needs and therefore won’t be able to complete his agreed functionality.

According to Scrum, we have two seemingly opposing forces:

  1. The end of sprint review where the team shows the progress for the sprint
  2. The rule that “only potentially shippable code” should be shown

The problem is that his part of the system is the user interface and without it the sprint review will be mostly white-board and some of NUnit tests. Not very exciting and not liable to provoke much discussion. So he asked the question - “Should I just hack it to get something on-screen”? I had to think about this for a while because it’s very tempting to say yes. I could almost justify it by saying that its demo code and will be thrown away. After, musing for a couple of minutes I said no for the following reasons:

  1. Rule (2) above
  2. The sprint review is designed to show project progress and demo code is not progress
  3. The act of hacking in demo code and pulling it out again tends to add entropy and hence bugs into the system

So a question for a future post should be “Why did I not clear the block (customer needs) for the developer?“.

This entry was posted in agile  and tagged #scrum  on .
Discuss this on Twitter or LinkedIn