Anti-Pattern: SCRUM Backlog as Refrigerator of Agile Software Development

 

This is a well known ant-pattern of software development with SCRUM. I call it the backlog refrigerator. I choose that name because of the same behavior of backlogs and refrigerators. Both accumulate old things nobody need and blocks space for more useful things. 

Following points that you use your back backlog as refrigerator and not as backlog:

1. Backlog counts more then 50 items
2. Some items celebrating birthday (are older then one year)
3. Multiple duplicates
4. Slim description tasks where nobody can't remember the reason creating it

How to solve it

1. Remove every task that is older then 4 weeks without inspecting it. Why? It's much easier to recreate a task instead of holding and discussing it. 
2. Next step is to avoid such kind of backlog refrigerator. Therefore you have to re-thing what should in your backlog. My advise, only user stories and only for two sprints. This keeps the development team focused and keeps your backlog in size.

 

PS: These advises works for your frige and your backlog.

SCRUM Beyond: Names

Every agile developer knows the the sprint as the time period in SCRUM. The idea to have short iterations is good and right. But there is something wrong with the Spring and thats ... the name. 

If you compare software development with sport, I know the stereotype of unathlethic developers, then it should be clear that you have to a relaxation time after an sprint. Usain Bolt can't run 10 mile in the speed of 100m . But as software developer you have no relation time. Software development is not like a sprint - software development is more like running a marathon. You can't work with highest possible speed, if you try it more then once you will wear your development team. Keep this in mind and don't call it SCRUM Sprint, call it SCRUM Mile.

SCRUM Beyond: Nano Demo an efficent Technique

 Every agile developer knows the three long meeting at the Sprint change: Review, Retro and Planning. As an improvement to keep the development cycle short, shorter then the spring length is to introduce a so called Nano Demo. In the Nano Demo the developer presents the in the last days finished tasks to the product owner or to the users. You can do the Nano Demo periodic every two or the three days. The Pro of the Nano Demo is the meeting is realy short 5 to 10 minutes. The developers need no preparation time and the feedback loop is very close. That gives immedently feedback to developers without any delay. A second positve aspect of the Nano Demo is the better motivation of the developers by the close feedback.

Summary:

Nano Demo is a efficent Review technique used to improve SCRUM.

1. 5-10 minutes short
2. every two or three days or two time in a week
   

PRO:

1. Close feedback cycle
2. No Preparation from the developer side needed
3. Keep meeting effort short
   
4. Improve developers motivation