Trials in Agile

Many times and for various reasons a product owner might be overwhelmed in carrying out his or her responsibilities. In some instances, the product owner’s job might be that of product owner along with other still existing business-side responsibilities. I have also seen instances where the product owner is the product owner for more than one team. In situation when the product owner is overwhelmed in carrying out his or her responsibilities, should the scrum master help to fill the gap? What types of things could the scrum master do in such a situation? I’ll examine these questions to follow.

First of all, as a servant leader for the team, I would say yes the scrum master should help the product owner with some of these types of situations with the understanding that the ultimate responsibility of the outcome or results of those task still lies with the product owner. The scrum master could help to pre-groom stories to get them ready for the team to examine and point. He or she could help to prioritize the backlog based off know business value or based off project specific dependencies or due dates. While doing this, the scrum master would need to share all changes made with the product owner so that product owner is aware and has the final say and responsibility for the end state of those activities. When it comes to final sign off on UAT, I would say that the product owner would have to perform that activity and the scrum master should not give final sign off. I would go further to say that the scrum master should not UAT stories as the product owner should be responsible for maintaining a close eye on the heartbeat of those product changes.

When it comes to the team, the scrum master should focus on making sure the team is following the process and by following good process it will produce a quality product. The scrum master should focus on helping the team constantly improve through performing retrospectives. He or she should keep track and execute action items for improvement through those retrospectives while also helping the team to remove impediments that it faces.

In conclusion, I would say that the scrum master helps to facilitate the process in all of its aspects, and that part of that facilitation would be to help the product owner if he or she is struggling. I can’t think of a better definition of what a servant leader should do than to help those on the team that are in need. What do you think?

A spike in scrum software development is a research story that the software development team creates in situations in which it currently does not have enough knowledge to accurately point the story. With that said, there are two different philosophies around whether spikes should be pointed or not. I will examine those alternatives to follow.

The 1st camp states that spikes should not be pointed as the whole objective of a spike is to do research work so that a document with the research work can be created and the design can be documented and so that a story can be created and pointed to do the actual work. This camp believes that due to the ambiguity of the situation how can you point something for which you have no idea what the design should be.

The 2nd camp states that spikes should be pointed. The idea here is that the spike can be pointed base off a time box for the amount of time it would take for the research work to get done. Ideally, a spike should not take longer than a sprint to complete, but some say that you can point the spike based off a time box shorter than the sprint in which the research work should be done. Say the biggest you allow a story to get before breaking it down is 13 points. Those 13 points would represent a whole sprint’s worth of work to complete the spike. Any lower than those 13 points would represent less time in a sprint to complete the work. You would still use the Fibonacci scale but just as a time box less than a sprint to complete the work.

I have actually defended both sides of the argument at one time or the other. I have been on teams where we exclusively did stories that were not pointed. On those teams, the spikes tended to get done within the sprint and would not roll over. The spike would get worked and the outcome documentation would get completed. From that documentation, we would create stories for future sprints and bring those stories into future sprints to get the software work completed. I have also been on teams where we did not point the spikes and the stories would just roll over from one sprint to the next, not getting done until a deadline forced the situation and the work had to get done. In those situations, we as team decided to point the spikes and that in turn helped to motivate and commit the team to getting the work done quicker.

I can see the benefits to pointing and not pointing spikes based on the unique needs of each team. Should we as an agile community have a defining, tried-and-true answer to this question or should the unique situation of each team define how we answer this? What you think?

Many time within agile software development teams, the business will try to sneak in work through the side contacting developers directly without going through the product owner or team as a whole. I as a scrum master has seen that happen more than I would like to count. With that said, there are a couple quick and easy things you can do to curtail this unhealthy team habit. Below are a couple suggestions:

1. Create an “unplanned work” section on your kanban board where developers can put work items that come to them from other sources other than the product owner. That way the work is made visible and the team, product owner, scrum master can address it with the team, create stories, and get the work prioritized by the product owner.
2. If unplanned work is injected into the team with enough regularity be sure to quantify it within your metrics so that stakeholders can see how this is affecting the team and also to help to get political backing for any solutions you would pose to help to get this unplanned work more formally introduced into the team through the product owner.
3. As a scrum master, be sure to protect the team from the product owner interjecting unplanned work into the team within a sprint. What I do when this happens is I ask the team “Can you complete this new story and still meet the commitment you made to the stories that are already in the sprint”? I take it to the team at that point and from there you can discuss a path forward and get the team’s buy in or not.

By following these 3 simple suggestions, you will be well on your way to protecting the team from the harmful effects of unplanned work.