Throughout the years, teams have become more aware of how important it is to properly embrace the Scrum framework. The use of proper engineering techniques, such as continuous integration or automated testing, conducting retrospectives, or having effective planning meetings with the customer, are some of the most common examples of Scrum acceptance. I have to admit that this makes me confident because it means that Scrum and some of the most important Agile principles are being properly adopted.
Despite all of this, there's one aspect that I believe hasn't been properly tackled by most teams: customer engagement in the context of the Scrum framework. Yes, it's true that teams have their planning meetings at the beginning of each sprint and review meetings at the end of each sprint. Let it also be true that teams are looking for continuous feedback from the client. However, what usually doesn't happen is a solid and supported continuous integration within the framework. How many times has the customer attended a planning meeting without knowing exactly what they need to do or what they should have prepared? How often is the customer's internal communication completely absent, preventing them from agreeing on the user stories and how they should describe them to the team?
These are just some examples that undermine the efficiency and effectiveness of the Scrum framework, having it unfairly blamed quite often for the failure (or limited success) of projects. My goal is to share the global strategy that I've been applying (and recommending) over the last several years to engage a customer. The key focus is to make sure that the customer is not only familiar with the team's tasks and activities but also with their own tasks!
Introducing the framework
Although Scrum is a fairly simple framework, introducing new concepts and a new approach to software development teams can make the customer's mission a bit more complex. Because of that, I put a lot of effort into making sure that the customer is familiar with the Scrum foundations.
Of all the new concepts and principles that Scrum introduces, the following concepts are the ones that I consider the most important for the customer:
This is the core concept for the customer to understand, as it represents the outcomes of a common language that will be used among the team and the stakeholders. Although it may be hard to have the customer write perfect user stories, I always help the customer make sure that the story clearly outlines the concept, the structure, and the goal. If this minimal requirement can't be achieved, the team will be facing serious problems throughout the entire project.
Still related to user stories but very close to the first version of the release plan, I always try to explain why we use the rough estimates and how we play Planning Poker®
. Above all, I try to make the client realize it's a complete waste of time trying to get detailed estimates at the beginning of the development cycle, when we don't even know the details of a user story. These rough estimates will allow the team to first come up with a release plan, which will be enriched and updated throughout the project, when the team has more knowledge about each user story. This is the key idea that I try to share with the customer.
Although the concept is simple, it's frequently confused with the sprint plan and the release plan. The most important aspect is having the customer realize that this is the "bag" where they can put their requirements that we would like to have as part of the final solution. Because it is not possible to do everything at once, this is when the prioritization of items plays a major role. The customer contribution during this prioritization exercise is paramount, and they need to be made aware of that.
This is one of the most important concepts that the customer must understand. The concept of timebox and velocity and how they determine the number of points that can be achieved during the sprint will help the customer understand how the functionalities will be distributed throughout time within a release plan. This will also make it easier to understand any change in the scope of a sprint as a result of a change in the estimates of a user story.
After explaining the sprint plan, we should ensure that the customer understands the release plan as the way functionalities will be delivered throughout the release cycle. The points assigned to each story, together with the concept of velocity (both previously explained), will allow the customer to understand what can or cannot be part of a release and why.
Calendar of activities
One of the most common mistakes customers make is to think that their role is all about showing up by the end of the project to validate the system. Nothing could be further from the truth, as we all know. Sometimes, making the customer realize and embrace the reality can be quite challenging.
One of the best tools that I've been using for the last several years is the activities calendar
created by Mitch Lacey. With this calendar, Lacey perfectly describes the recurring events that involve the development team and the client throughout each sprint. Although all the events are relevant, for the following events I make sure that the customers understand how critical their role is in each one.
This is probably the most important meeting during a sprint because it's when the customer provides all the necessary details for the development team to build the user stories planned for that sprint. I also ensure that the customer understands that this meeting is actually prepared in the previous sprint (through story workshops, grooming, and backlog prioritization).
I always tell the customer that this is the moment they have in each sprint to review the scope and start preparing for the next sprint. After becoming familiar with the concept of a user story, they will happily dedicate some time every sprint to ensure that the backlog has the appropriate user stories, creating new ones or updating existing ones, if necessary. Sometimes, as a ScrumMaster, I join the customer during these meetings to help them create or update user stories.
The customer needs to be aware that the workshop is useless unless they communicate and explain to the development team the output of it so that the team can evaluate and provide a first rough estimate on those changes. This will keep the backlog up to date, allowing the customer to decide on the priorities.
After the grooming, the customer has the necessary information to perform the reshuffle of the backlog according to the priorities they defined. Depending on the complexity, this task is often completed together with the grooming. The customer understands that after completing this task, the backlog and the release plan will be up to date and ready to feed the planning meeting during the start of the following sprint.
This is definitely the easiest event to get the customer to attend because it's when the team will demonstrate the user stories they've completed during the sprint. Nevertheless, the two following aspects are important to mention:
- There's nothing wrong with finding a couple of bugs, as this is an inherent part of the process. The team should accept this reality and proceed with the demo. At the end, the bugs will be put in the backlog so that the fixing can be planned.
- The development team should cancel the review meeting if they're not comfortable or confident about what they're about to demonstrate. Although there's nothing wrong with a couple of bugs, too many bugs will cause frustration among the users and trigger a sudden lack of trust.
Inputs during the sprint
The review meeting at the end of each sprint is one of the key sources of feedback from the customer. This is a well-known truth. But, in addition to the review meeting, I usually use another strategy to collect feedback in a continuous way.
Instead of waiting for the end of the sprint to present and validate the user stories, I encourage all teams to provide the stakeholders with a new version of the application every time a new user story is developed and tested. This informal approach will give the stakeholders the freedom to test it on their own workstations and get familiar with the functionalities. For those who don't feel comfortable during the review meetings because they somehow feel the "pressure" to validate something, this is the perfect scenario. By the time they get to the review meeting, they are already familiar with the functionalities, turning the validation process to a mere formality.
Define the stakeholders' schedule
Because it's a key point for the success of the project, it's very important that the stakeholders commit the necessary time in their schedules to perform the most important tasks. Without doubt, the best opportunity to have them perform the tasks is after explaining the calendar of activities. This is the moment when everything makes sense. If possible, do it when the development team is also committing their time, as this will reinforce the attitude of "we are all in this together" and foster the spirit of a unique team.