Changing your Sprint Length

So we recently undertook an "experiment" to switch our sprint length from 2 weeks to 1 week. This was due to a high priority project that needed some extra visibility and ability to "course correct" if something came up.

Here are some things to keep your eye on if you decide to reduce your sprint length:

• Meeting Overhead - You are now doing your sprint planning, review, and retrospective more often. While some may say that these meetings need should be reduced in length, the reality on the ground is that the shift in sprint length causes enough of a change where the meetings will likely take the same amount of time.
• Product Owner Time frames - With a two week sprint you get 2 backlog grooming sessions before the next sprint starts. That allows you more than enough time to get the backlog estimated and in order to ensure a smooth sprint planning. With only 1 backlog grooming session, the churn is constant and its harder to stay ahead of the team. Remember if the team decides to quickly move in another direction, you also have to keep your management aware of the changes.
  
• Work Size - The team is quite used to 2 week sprints. There is a comfort level with the size and estimate of the work. With 1 week sprints you can easily find it difficult to know the right amount of work to take on.
• External Tasks - A 1 day vacation or an illness of a team member because material. All day meetings or long 2-4 hour meetings become material and difficult to manage. Don't forget to plan accordingly.

Be mindful and aware...if you know these "gotchas" ahead of time you can prepare and mitigate accordingly.

When the Product Owner has to say no

I read the following blog post "When the Product Owner has to say no". Intriguing but I could resist the urge to comment.

The scenarios where Product Owner has to say no in the blog post were quite true. To me, the Product Owner has to be able to say no and sometimes make those difficult trade-offs between which customer or internal stakeholder gets what they are asking for and which ones have to wait. Until you've had to sit in front of a VP and explain those trade-offs and why that VP didn't get what they needed, you haven't earned your chops as a Product Owner.

Here's what I take issue with the conclusion: "Many NOs accumulated in the course of a project are a symptom of a failure in the PO performance." While I have no problem taking responsibility for my actions and learning from them. I do think this type of broad generalization leaves out of a lot of key facts:

1. Sometimes the Product Owner has to say no to an internal stakeholder in order to keep the team focused on its goals and commitments. This is not due to a failure in PO performance, but rather a lack of focus from other folks
2. The Product Owner is part of the team. While some may say that they are the single "wringable" neck, I'd like to think that the team can self-manage to prevent these types of unwarranted behaviors.
3. Part of the role of the Scrum master is make sure that the team is acting agile and following scrum practices. Many of the issues noted by the author of the blog post indicate a lack of leadership on the part of the scrum master.

I'm all about taking responsibility, but I'm not about the "blame the product owner" for everything mentality.