Scrum Notes: If It doesn’t fit, don’t force it.

Sharing is caring!

This article will share and invite you to discuss my mistake during sprint. I’m open with any thought and discussion, by give a comment below.

Doing estimation in software development is difficult and can be very challenging. Especially if we work too long in adopted predictive process in the workplace. As Ken Schwaber & Jeff Sutherland says in their book, software development projects are at least complex and sometimes chaotic.

This condition made developers or any parties involving in the project add buffer in their estimation. If we really honest, most of the time, we made estimation out of nowhere because we are uncertain about things.

On other hand, management usually is stubborn and avoid to face the reality. Instead of sit down together and make some understandings, management insist and force their team to deliver the features.

The Situation

Condition above often create a pressure to team. Team will tend to obstruct Scrum rules. This also happen to me, when I try to decide whether a backlog will put in a sprint or not.

To make that kind decision, we use a method to estimation called “clothing size”. We define effort as shown in picture below:

Any backlog with size XL, we will discuss and try to make it smaller. If we think it is big, we will slice it vertically. By doing this, we encourage team to be honest and give a realistic opinion about how they see the backlog. We slowly able to elicit ‘buffer’ since they feel safe to express what we know.

The Mistakes

The team still new in adapt Scrum. I realize the problem is not about the Scrum framework itself, or about team understanding of the Scrum. Instead, the main problem is we still keep old paradigm when we try to be agile.

Once sprint, in the planning meeting, we conclude there is not many backlogs we think small enough to put in sprint. We find only around 2-3 story with total estimation around 40. In this case, our project manager (yes, we still have project manager role in our Scrum. Don’t blame us) demand that we still have capacity and suggest to put 1 or 2 more.

There is 1 backlog with estimation XL (80 points) which our project manager think the requirement is clear. Problem is we don’t have experience yet to turn this backlogs. What we know is some members have experience in limited area, and the members insist it will require much works.

In the end, we add it to sprint and make it worse by decrease the point to be 40 (L) just to keep the game rules. We can guest what probably happen: we make small increment done, and we stuck on one “XL” backlog. There is no much progress in it, since member still try to get the knowledge.

To summarize, our mistake in this note:

1. We tend to make management happy. We put unclear backlog just to give management sense of progress.
2. We play (or bend?) the rule just to make it happen, rather than as a guidance that make us sane.

Lessons learned

Now, as human, we have chance to learn from our mistake. I made several conclusion base on my mistake.

Keep honest

I try to suggest keep honest, either to the team and management as stakeholder. I think management need to value honesty as element of being transparent. Being honest have a meaning that we embrace the fact, regardless it is good or bad.

Try to elaborate more with in scrum events

Several things we know before the mistake happened:

• Requirement is clear.
• There is no expert that made our team become cross functional. We may have some members with some experience, but team don’t have confidence about it.

Based on what we know, I learn and make suggestion as follow:

• Elaborate what team can do by use Sprint Planning and Product Backlog Refinement meetings. By use the event, we expect to gather some ideas or alternative that we can do.
• Encourage team to be honest, make them feel safe. Give space to team to express why they think it’s too complex.
• We need to pay attention about cross functionality aspect (will write about it later). If at the time, we empower product backlog grooming well, we might have several option about team cross function to note for upcoming sprint.
• I saw that Product Backlog Grooming is a chance for the team to elicit some undesirable variance during sprint. We cannot eliminate all unknowns, but we will have better understanding and plan for next 2 weeks. Use this event to do brainstorming a lot!

Update: In the end of sprint, our member who have some experience able to make some progress in that backlogs. The backlog still incomplete, but we made progress.