Lisa, an agile project manager, dutifully completed her project status deck every iteration to send to her leadership. She hated creating that deck for several reasons: she knew the data she reported wasn’t the data the senior leaders needed.
Some of the leaders still wanted to know the schedule variance—which made no sense in an agile project. Other leaders wanted story points—or worse, the story points an individual delivered. She flat-out refused to even consider that as a measure.
Some leaders even wanted her to create a Gantt chart for the entire project, even though the team only planned for two weeks at a time.
She’d offered them alternative measures, such as cycle time, defect escapes, and team satisfaction. Her leaders didn’t want that data. They wanted much more traditional data.
Lisa was worried that her leaders did not understand how the project was proceeding. Right now, the project was in trouble because the cycle time was long and too many people were multitasking on other projects. She knew that the project was headed to a watermelon status. That’s when the project looks great for a while, but all of a sudden, the status turns red. That’s the watermelon—green on the outside, red on the inside.
Lisa needed a new plan.
Before she tried to convince her managers—again—that they needed different measures, she decided to try telling the story of several personas as status. She reasoned it this way: If they built the product using personas, maybe she could explain the state using personas. She could then explain the team’s progress, persona by persona. Maybe then, she could explain which measures the leaders could use instead of their current requests.
First, Lisa explained about the personas.
Explain Personas to Leadership
In the next deck, Lisa explained that the project for their lab product solved problems for several primary personas:
- The admins, who were able to access everything.
- The supervisors, who could access almost everything and manage what the lab techs did.
- The lab techs, who had limited access to the database and the procedures.
As the leaders nodded their heads, she said, “And we finish features at different rates for each persona.”
The sales VP, Steve, frowned: “But we need all of the features.”
Lisa replied, “We might. But even if we do, we can’t start and finish them all at the same time. If we did, you might not see the whole release for months, instead of something useful every week or two. That’s why we’re spending this iteration on the admins. They need to update the lab values so the techs can do their work.”
Steve said, “So then you’ll work on features for the lab techs?”
Lisa nodded and said, “Partly. We expect to do some features for the lab techs and some for the supervisors.”
Steve said, “I didn’t realize you staggered work like that.”
“And now you know,” Lisa said with a smile. “Now, let me explain what we finished for the admins, telling you how they work.”
Use Stories to Connect with Your Audience
Lisa started to demonstrate the completed features for the admins. As she explained the story the team completed this week (about the control values for the lab techs), Steve interrupted her: “How does the admin know the control values?”
“We ship with a range for three experiments,” Lisa answered, and showed him. “Then, we created this edit screen so the admin can create more values.” She showed him that, too. “Make sense?”
Steve nodded. “It makes a lot of sense. Now I understand why my salespeople are raving about these changes. Also, who the service reps are. You made it so the admins, but not one else, can import a spreadsheet, too, right?”
They spoke for a couple of minutes about how the different kinds of users could use that functionality.
Then, Steve asked, “So, how do the supervisors schedule the next lab experiments?”
“We’re not there yet,” Lisa said.
“Well, I want to see that next week!”
“Sorry,” Lisa said. “We’re not going to touch the supervisor stories for another couple of iterations. If you want those stories earlier, please talk to Polly, our product manager.”
“Where is she?” Steve asked.
“She couldn’t be here today because she had other commitments,” Lisa said.
After several more minutes, Lisa completed the demo.
“Will you demo like this every week?” Steve asked.
“I plan to,” Lisa said.
“But why didn’t you complete more than one story this week? Why did you make that story so big? It didn’t look that big when you demonstrated it.”
Lisa said, “The team is trying to multitask on several projects at one time. As a result, they only completed this one story this past week, the one about the control values.”
“But we want the team to finish more,” Steve said.
“I do, too,” Lisa said. “That’s why I’ve been bugging you about deciding which project you want the team to work on when. You can see we’re not making the progress we want to make. Decide which project the team will work on and we can finish more.”
Demos Help Your Leaders Understand Project Decisions and Status
When leaders understand the project decisions, they are more likely to understand the project status. Here, Steve and the other leaders didn’t need a lot of time to understand the project’s decisions and current state.
Steve might not have liked Polly’s ranking choices, but he understood those choices. And while he didn’t like Lisa’s comments about multitasking, he could see why she wanted the leaders to decide on one project at a time.
Over the next several weeks, Lisa continued with the weekly demos, explaining the status by persona. One week, she included the testers as a persona, because the team needed to create scaffolding for test automation.
That’s when she explained that the automation allowed the team to change features more easily.
At first, the leaders didn’t like the fact that the team created stories for “themselves” instead of the customers. But once the leaders saw how easy it was for the team to change the features, the leaders understood.
If you also worry about watermelon status, consider what and how you communicate your project status to your leaders.
This article was originally published by ProjectManagement.com at https://www.projectmanagement.com/articles/842368/no-more-watermelon-status-reports–how-to-use-stories-to-explain-project-state. Reproduced with permission of ProjectManagement.com. Copyright © 2023 ProjectManagement.com. Unauthorized distribution of this content is strictly prohibited.