What kind of software team are you in?
Suppose we consider two teams, and we look at their productivity during a Scrum sprint:
Both teams had five stories to do. Team A did not even start on the fourth and fifth stories!
So, it definately looks like team B did much more work! At least, that is what the colouring suggests. However as it turns out the number of finished stories in Team A, being two, is higher than the number of stories finished of Team B; they got nothing finished at all!
Even if Team B absorbed extra work, like fixing some production issues or other ‘hidden work’, that might not be so clear to the rest of the company who only looks at the finished stories each sprint.
What should team A do?
According to agile team A probably has a good definition of done. Their DOD means team A is finishing stories and ensures the work is fully done, tested, shown, and proved to work before they start on a next story in the sprint.
Apparently the team estimated to many stories for their sprint though. The team might evaluate their estimations for the sprint and adjust accordingly.
What should team B do?
Team B should consider the presentation of what they do, and how that is perceived in the company. It might be much better to actually take some actions. Not finishing any stories, while perceiving a state of 80% of done on all stories does not make those stories done. That’s not working towards a potentially ship-able product item, unfortunately. Basic actions that team B could consider are:
- Stop starting, start finishing
- Do less instead of more
- Focus on one thing at a time
- Keep ad-hoc work out of the team
Both teams probably have to work through their DOD’s; evaluate when work is finished. Usually, a company prefers teams that are reliably producing steady increments of work. Work on becoming predictable what can be delivered supports transparency in the organisation