About: Ruben Betancourt

Recent Posts by Ruben Betancourt

Have you seen a team that doesn’t understand the reason behind developing certain feature? Have you had a sprint review where more than a half of the features are rejected? Or that the team develops a huge feature that doesn’t add any significant value to the product? If you’ve seen this in your project, it might mean that your Product Owner is doing something wrong.

We can consider the Product Owner to be the main stakeholder. She should own the product and determine direction. The reality is that the Product Owner role is different from that of a project manager, since she has the passion, the vision, and, unlike a project manager, has to say no to people. Let me explain.

Saying NO to stakeholders.

On a typical project, the team delivers a certain amount of story points per sprint. But it’s common to see that once stakeholders notice what the team is capable of doing, they start asking for more and more stuff. Imagine that certain project has around ten stakeholders, and each one of them suggests a new idea, which represents, let’s say, two story points. The problem is that the team is only capable of delivering ten story points per sprint, and if we let this situation run out of control, then we will end with an infinite queue of pending work.

The Product Owner is the one in charge of prioritizing the work queue. More than that, he is the one in charge of preventing the creation of that infinite queue of features, and the only way to do it is by saying NO to stakeholders. At least from time to time.

It’s true that the Product Owner must develop a good relationship with the stakeholders, and part of this is helping them decide what should or shouldn’t be part of the product backlog. By having a clear product vision, a well-studied market, and regular interviews with end users, the Product Owner should be able to determine what features are the best for the product.

Saying NO to the current backlog

The business value produced by each feature tells the PO what should be the priority for each story. Let me clarify, when I say value I’m not talking about the size in story points, I talk about the actual ROI of each story.

The Product Owner should be skilled enough to find out the real value of each feature, by studying end-user behavior and market trends. Let me give you an example of that.

“Jim Employee” is part of the marketing department of a graphic design company that sells templates to graphic designers. On a sprint review, Jim proposed to add a small countdown clock right below the daily offer section. The only problem is that his requirement was down the road in the backlog because of the urgent features that the accounting department has requested.

“Mark Product-Owner” decided to support Jim with his idea and he put it at the very beginning of the next sprint. After an (expected) argument with accounting, he stood his ground, and the team developed Jim’s idea.

At the end, that small requirement increased sales, and it wouldn’t have been possible without Mark’s support.

What if one of the stakeholders proposes a simple change to the interface that improves the end product a whole lot? If the stakeholder doesn’t have enough influence and there’s a lot of pending work on the backlog, chances are that the feature could stay in the backlog forever. It is the product owner’s job to support good ideas that have high value.

Saying NO to the Scrum Master.

It is true that the scrum master is the one in charge of making sure that Scrum is followed as intended. However, there is just one person that can say no to the Scrum Master and change a sprint’s path or add features, and that is the Product Owner.

According to Voltaire, “With great power comes great responsibility” and, in this case, that quote applies very well. The Product Owner is the only one that can say no to the Scrum Master, and if she doesn’t use this power wisely the team could end with a useless Scrum implementation.

But, when can a Product Owner interrupt a sprint? There is no rule for this; it depends on the urgency of the requirement. As a rough guideline, I could say that most of the time a sprint can only be interrupted because of the appearance of an urgent bug on the production server. It is the Product Owner and the Scrum Master’s job to exert their judgement and decide when a sprint can be interrupted for the sake of the project’s health. Nonetheless, the Product Owner has the last word.

Saying NO to the team.

It’s the team’s job to think outside-the-box. However if they didn’t have any external boundaries to keep them in check, the product could easily become something different than what the market, users, and the company need and want.

One example of this happened to me when I was Product Owner of a project that started as a small demo to a group of investors. After a few months of work it became a more serious networking application.

On a Sprint Review Meeting, one of the most experienced developers of the team asked me to spend a significant part of the upcoming sprint time on redefining the architecture of the application. He explained to me that the design that we had up to that point didn’t fully support the new requirements, and we had to do it right away.

At that time, we just had one “urgent feature” to develop, so it was easy for me to say yes to that. I wasn’t sure I had made the right decision until some time passed, and the velocity of the team went up. When I asked about what changed, they told me that the new architecture was allowing them to develop things faster.

Later, I received a suggestion from the same developer about moving to a NoSQL database. According to him, that database model offered better compatibility with what the product was becoming. I analyzed the situation, asked for some advice and I decided that it wasn’t a good idea to proceed at that moment with the change. We were far away from launching the product and, even though we were near to the deadline, the improvement on the application’s response time wouldn’t be significant.

In other words, the Product Owner is in charge of making room where the team can experiment with their ideas.

Having a great relationship with everyone.

I’d say that this is the hardest part of the work since this involves a lot of what some people call “soft skills”. It involves leadership, friendliness, persuasion, and more.

The Product Owner must have a good relationship with her team and become the main bearer of the product’s vision. She or he should maintain a good relationship with the Scrum Master since he will help her to mediate difficult situations and will support her with the improvement of the Product Owner’s performance. Finally, she should maintain positive relationships with the stakeholders. They are her customers, investors, and end-users. Without them, the project wouldn’t be possible.

The Product Owner role is a complex one that needs skills and knowledge in professional communication, user experience, and market research. At TangoSource, we have internal Product Owners who act as the eyes and ears of our customers. They are in charge of interviewing the stakeholders, studying the market trends, and defining the features of the project. Ultimately, they’re responsible for the results at the end of the sprint.

Want to know more about how we run Scrum within the company? Drop me a line or follow me on Twitter, I’ll be glad to strike a conversation.

A couple months ago I heard one of our team members say that “Scrum wastes a lot of time on meetings” and that “most of them are not even necessary”. If we look at this idea from the developer’s point of view it’s understandable, being part of a Scrum ceremony, listening to everyone when sometimes the topic has nothing to do with her role or feature, might seem boring. But did you know that a single team member can screw up an entire project (even without noticing) by not following a scrum process correctly?

According to the methodology, there are some events in which the developer has to participate, but there are other equally important tasks that the developer needs to do to help with the larger development process. In this post, I’d like to do a quick review of the five ceremonies of Scrum to help us reconsider their value. So, first things first, let’s begin with…

Definition of Done

Contributing to the creation of the definition of done is important for a successful development process, since having an unclear definition might cause misunderstandings, eg: miscalculating the remaining work for each feature, incorrectly estimating the features at the beginning of the sprint, or not being clear on if a story should be delivered within a sprint or not.

The team shouldn’t make the mistake of leaving a single person (usually the Scrum Master) to write down the definition of done. Making a good one is a shared responsibility between all the team members and the Product Owner.

To accomplish this step all the team members should share their opinion about what should or shouldn’t be part of the process of delivering a feature based on their experience and their team dynamics. For instance, if their experience says that they should do TDD or that the team works better with small pairing sessions instead of pull requests for code review, they have to share their thoughts to make a Definition of Done that fits their specific needs.

On one occasion, on the last day of a sprint, one of the team members finished a feature he had been working throughout the sprint. He could not deploy it to the staging server since on that day there was nobody that could review his code. During the daily stand up he didn’t report it as an impediment because, from his perspective, the development process had ended when the coding phase had finished. At the end of the day, when the Product Owner checked the work from a local computer, and in spite of the fact that the feature was technically working, he considered it to be useless because he wasn’t able to show it to any stakeholder for testing. When I was asked for my opinion (and observing it from an external point of view) it was more than obvious that there was a failure in the definition of Done. For the Product Owner, it was required that a feature was on staging to marked as complete. Unfortunately the development team never had it clear.

After talking about the situation, the team stipulated in the definition of done that in the case that a code review couldn’t be performed, the developer would have to do a code refactor by himself. But for a feature to be considered as completed, it must have been deployed to staging.

After all, there is no “correct” or “incorrect” definition of done, but there is a correct way to go about defining it. Collaboration is necessary.

Backlog Grooming Meeting

In this ceremony, the developer will clarify all the stories in the backlog and should accept or reject them as a part of the next sprint.

There can be no trace of doubt afterwards: The developer has to remember that the stories presented in the backlog grooming are items that she will be working on sooner or later. It’s very important to clear all doubts and vague concepts no matter what, and be aware that there are no stupid questions if they help to fully understand the stories.

Technical challenges: When the developer is asking questions, it is also important to think about their implementation. For instance, the knowledge that she has about certain tools or programming languages. Sometimes, there are technical limitations that won’t allow for the development of a story as it was designed initially.

Take a look at the current code base: It might happen that the Product Owner asks for a feature that sounds easy to implement, but when the code is analyzed the realization comes that it will be much more complicated than originally thought, because of the current code base. If a development team keeps the big picture in mind, they will have a better idea of how to implement each feature and be able to ask smart questions based on that. It is easy to fall for this when new team members enter a project, or when the team starts working on a part of the application that hasn’t been touched for a while.

The team has the control: The team needs to remember that they can reject the stories if they are not well described or if they can’t be developed with as requested. Even when the story is simple to the naked eye, it’s always better to write at least one acceptance criteria.

Sprint Planning Meeting

As we’ve already seen, it’s important to answer any questions that the team may have about the stories. Once every question has been resolved, the team will proceed to estimate the stories. Regardless of the estimation method, there are some points that every team has to consider for a proper estimation.

Make conscious estimations: It is always a headache for the development team to make a precise estimation for the stories, however it is important to try our best to avoid over or underestimations. That’s because, down the road, the team will use those stories for reference purposes, and if they are not even close to reality, future estimations will be affected.

Keep in mind the Definition of Done: once the team is doing the sprint commitment, it’s easy to forget about the definition of done. It is essential to always keep in mind the whole set of steps that make up for it to avoid over-commitments.

Looking at the history: It is necessary to consider previous sprints as a reference for the incoming commitment. A useful rule, do not make a commitment of more than what has been delivered on the previous 3 sprints.

Daily Standup

The daily standup meeting might be the most important ceremony in Scrum since it’s all about keeping the team coordinated between them. This is the moment when the team can share to each other about the progress made, impediments, achievements or any relevant situation that the team needs to be aware of.

Believe that somebody else can help: it is very common that one of the team members can’t realize that he has a blocker. This is where the Scrum Master comes to the rescue. It is important to be humble here and remember that the Scrum master is the one that is overseeing the process and he can easily discover when somebody needs help.

One step at a time: another good practice here is to use this event as a “commitments ceremony” to be able to determine if a story will require support from the Scrum Master. If the team members make small commitments on a daily basis, it is easier to remain focused on the sprint goal.

Sprint Review

At Tangosource, instead of having a meeting for this at the end of each sprint, we have daily reviews done by the Product Owner.

We have a golden rule when testing and reviewing: “Go by the acceptance criteria”. It sounds obvious, but it’s easy to forget sometimes. Before delivering a story, we make sure that we have double checked that every criteria has passed. By following this golden rule, the development team ensures that the story is achieving the goals that the Product Owner wanted, lessening the possibility of having a rejected story.

Sprint Retrospective

In Scrum, each ceremony has its own importance, and this also applies to the sprint’s retrospective meeting. Once the team has finished the sprint, it’s time to talk about what just happened. There are many ways to do this, but the one we have found to be very useful is answering three simple questions:

What should we continue doing?

What should we stop doing?

Are there any ideas to improve as a team?

A common mistake is to skip this ceremony under the excuse that is not as important as the other ones, and that the team can use that time for a more meaningful activity. But remember, if something went wrong during the previous sprint and the team didn’t have a discussion about it, chances are it will happen again soon. I saw one example of this when a team had had a couple of sprints without delivering much value. From the Scrum Master’s perspective, the obvious reason was because the Product Owner was adding features at the middle of the sprint. Because of the rush, the team had been skipping the retrospective for 3 weeks in a row under the excuse that there were urgent bugs to deliver. When I was invited to analyze the situation, I gathered all the team members to talk about the project’s issues, and one team member wrote down that the technical debt of the project was making it difficult to incorporate new features. By talking about that, the team realized that they should have focused their effort on solving that situation first, and that once they had solved it, adding features mid sprint was not going to be a problem anymore.

After a couple of sprints I took a look at the project again, and it turned out that they were delivering features and that the sprint disruptions reduced a lot. We can see here that the Sprint Retrospective is a valuable ceremony for the Scrum process, and that if the team talks about the issues that they are having, they can improve their performance and the value delivered each sprint.

Final thoughts

It is true that the Scrum Master is the guardian of the methodology, and that he or she should lead the process, but a successful project involves more than excellent work from the Scrum Master and well defined requirements. Scrum is a methodology that helps the team to succeed in the software development process, but it requires that every team member is committed to support it.

Thanks to my friend and co-worker Jonatan Juarez who contributed on the creation of this post.

Want to know more about running Agile on your organization? you can contact me by e-mail or follow me on twitter