Five Scrum Short Stories

Five Scrum Short Stories

When I was first introduced to Scrum, I thought “What an easy and beautiful way to be efficient!” After years of doing Scrum, I found that it’s not that easy. It was easy to learn. And, as many times before, “easy come, easy go” was true. It was very easy forget easily learned facts of Scrum. I’ll tell you about some of the traps me and my friends experienced during Scrum implementation. Solving these was more or less successful, but if you recognize at least one of them in your environment, which you weren’t aware of before, my article was a success. I will tell you five real stories about people who were on the edge of Scrum and how they succeeded in avoiding Scrum traps. My Scrum heroes’ names have been changed to protect their identity. Let’s begin.

Proxying Product Owner

“Beware of the ScrumMaster who thinks that he can permanently assume the Product Owner role,” I would say. I’ve heard a similar saying before, “A good ScrumMaster can handle two teams and a great one can handle only one.” If you try to do the ScrumMaster and Product Owner role at the same time, you’re doomed. You won’t be able to perform both roles correctly – that’s certain.

One day, Scott was told at the very end of a Sprint that the Product Owner on the project had to move to another project that had stalled. He was told to act as Product Owner proxy for some time. Scott and the team were in a highly dynamic and quickly changing business, and it was a pretty tough period for the team. The first issue Scott was facing was time. The Sprint was one week long, and he did partially succeed in resolving impediments and barely succeeded in preparing acceptable user stories during the first Sprint. The second Sprint was a total disaster. Impediments started to pile up, and Scott didn’t succeed in preparing acceptable user stories. The Product Backlog was filled with a few essays, without good, smaller user stories. And Scott was a pretty good problem solver. He would have certainly been a great Product Owner, if he was focused only on this role. Simply, Scott didn’t have enough time to do both roles well for the team. Another issue Scott experienced was context switching, but maybe this is the wrong term. A better term is perspective switching. That was very stressful. At one moment Scott was trying to solve impediments and at another trying to figure out which story would return the investment in the best way. How did Scott deal with this? He didn’t. He told the stakeholders to delegate a new Product Owner. Even a non-experienced Product Owner is a better solution than a ScrumMaster acting as Product Owner proxy. Luckily, Scott’s Product Owner returned and he was able to keep Scrum on the track.

ScrumMaster as a Team lead

Claire had a pretty strong technical background on system administration, networks, and Java software architecture/development. Top management considered this to be a great asset to the team she was supposed to serve as a ScrumMaster. Because top management had a foggy understanding of Scrum, Claire was considered to be a “Team Leader.” Claire was the most experienced programmer in this team, but didn’t even have the role of developer. The other team members were really great developers and quick learners, but new to Scrum. They didn’t quite understand the nature of her engagement in the project, even though she had tried to be pretty clear about her role. They knew Claire before this project and had respect for her as a developer. I suppose they expected her to deal with technical issues using her remarkable experience. This asset started to become a great burden for the team and for Claire personally. She knew that if she got deep into coding she wouldn’t be able to act as a good ScrumMaster. The first Sprint Planning Meeting started, but when technical debt was discussed, everybody looked at her, expecting her valuable opinion. She remembered something that she heard once from a more experienced Scrum Coach. She asked the team to excuse her for some time and to continue the technical discussion without her. They were surprised, but after she left, they did continue. After some time she returned and they barely noticed her. She was satisfied with the result. When the meeting was finished, she asked the team if everything was ok and how they decided to address technical solutions. Everything was fine and the team was satisfied because they handled everything themselves. She suggested that they would feel better if they made decisions on technical stuff, and that they were very good developers. “Of course,” she said, “I’ll give suggestions if needed, but I’m not supposed to make decisions. The team has the power to decide. My job is to serve the team and to be sure that the project and work are running smoothly.” Claire made an “impediment list” sticky note on the wall and asked the team to give her tasks whenever they wanted, no matter what issues they might have. Then they really understood her role on the project.

Support Departments Don’t Use Scrum

Robert was a Scrum Coach for a software department that developed in-house projects. They had used Scrum for almost a year, and were doing a great job. When Robert came to the company, the department was pretty messed up, but in a few months everything fell into place and the teams became hyper productive. This was recognized by top management, teams were regularly awarded, and everything was fine. But Robert was a little worried. At first, he was focused on the teams, and wasn’t able to see the whole picture. Using Scrum, real issues were surfacing, but he was focused on the issues he had influence over, and the team was solving them. So, when impediments inside the department were minor, other impediments became visible. The first sign of trouble was that the Product Backlog was pretty empty. He talked with Product Owners and discovered that they couldn’t get enough information to create acceptable user stories. “Why?” he asked. Simply put, nobody from other departments had the time to define what they needed, and when they needed some functionality, they needed it immediately. From his perspective, communication with other departments was an impediment, but he felt responsible to initiate the solution. Now, because teams were pretty self-organized and doing well, it was time to spread Scrum to the other departments. First he talked to top management about the situation in other departments and presented the idea about introducing Scrum. They hadn’t originally considered it, but were pretty satisfied with the re-organization of the software department, so they agreed. Robert explained that he didn’t want to make this transition top-down, but would try with volunteers. He invited heads of each department to a working breakfast and explained Scrum, presenting potential benefits for the department using its principles. He asked them to bring a few team members to the next three meetings about Scrum. They were pretty shocked when he introduced some of the Scrum games, expecting a PowerPoint presentation. “Hey, you didn’t even bring your laptop,” they said. “I don’t need it,” Robert replied. After playing two games, he conducted a practice retrospective meeting, allowing the teams to reach their own conclusions. Then he helped them to make parallels with real situations that they were dealing with. It was quite refreshing and revealing for most of them. Then, he explained that Scrum was not a silver bullet, but a tool that could help them to understand the impediments and to enable them to work better. He asked them to consider it and to let him know if they would like to try Scrum in their environment. The next day, the chief of the technical support department contacted Robert, claiming that his team was overwhelmed and eager to try Scrum. “Great!” Robert said. “Let’s start preparations for our first Sprint.”

Disputed Definition of Done

Ulrich was a pretty experienced Scrum Practitioner. He knew that coaching a new team was going to be tough. They were all experienced programmers, but new to Scrum. Initially, coaching was tough, with much resistance and conflicts; a bumpy road that was now almost behind him. Eventually, things were much smoother because he knew the team’s velocity and the team knew their velocity, which was much more important. Velocity was regarding to “DONE DONE” user stories. He remembered the issue the team had with this, their definition of done (DoD). As he explained at the very beginning, the team and the Product Owner had to reach an agreement on this. One of the guys came up with a DoD proposition, and the team and the Product Owner were ok with it. One of the items in this list was “unit test coverage of 80%.” After the first few stories were “done,” he asked the Product Owner to test the items from these stories. With the tool they had, it was easy to see a unit test coverage of 23%. Ulrich asked the Product Owner what he thought about that. He answered that he wasn’t satisfied with that the result. “Why?” asked Ulrich. “Because these stories are not done,” replied the Product Owner. “Do you need a unit test coverage of 80%?” asked Ulrich. “No, I don’t know why they chose these figures, but if the team defined these, I expect them to meet these criteria,” answered the Product Owner. And he was right. The Sprint ended the next day, and during the Sprint Retrospective, Ulrich announced that the Sprint had failed, which provoked a very emotional response from the team members. He explained the reason and showed them real figures on test coverage. “But why is this important? We did all the necessary tests. We didn’t want to waste time unit testing trivial methods, such as getters and setters, and we didn’t want to test something covered in integration testing,” screamed the guy who purposed the DoD criteria. “Yes, you are completely right, but you promised something about unit testing and this was not accomplished. Could you tell me how you determined the proposed DoD?” Ulrich asked. “Well, I didn’t know what criteria to propose, so I copied some from a Scrum blog, which looked great at this time.” “Ok, guys,” Ulrich said, “this is my failure as Scrum Coach as well and it’s my fault that you didn’t understand the meaning and importance of DoD. DoD is different from team to team and project to project. This is not a general standard that should be implemented in all situations. And Scrum is not a standard that can be implemented the same way in all situations. Those are tools, which help you make better software, but you need to involve your intelligence, energy and creativity to make it happen. Ok, let’s do the job. Let’s create a DoD acceptable to us and our Product Owner. You are experienced developers and you know everything about good programming practices. You’ve seen one of many possible DoD’s. Let’s make new a DoD we can commit to.”

Estimations in hours

Marianne was inexperienced, but passionate about Scrum. She started her first Scrum project with the team and was thrilled, anticipating her first ScrumMaster job. The team knew about Scrum and was interested in trying it. Before the first Sprint Planning Meeting, the Scrum team agreed on some conventions and one of them was estimating user stories and tasks in hours. This was the natural choice for the team and Marianne agreed with that. Estimating in user story points was awkward to the team, since they couldn’t figure out how to correlate this to some real measurement unit. So they started their Sprint meeting and started estimating. They estimated all user stories and chose ones they could commit to finish until the end of Sprint. Then, the Product Owner stood up and spoke. “Well, guys, you just committed to finish user stories worth 230 hours and you have 400 working hours in your Sprint. Even if we add 30 hours for the meetings during the Sprint, still there’s 140 hours in the Sprint you should commit to. Is my math correct?” “Yes, you’re right,” said the senior developer, “but a working hour cannot be equal to a development hour. We have to have time to think about the story, business process, architecture etc. So, coding functionality is not the only job we’re working on. Development is the intellectual process, not an exact, simple operation. We really didn’t underestimate, in my opinion, and we didn’t want to „steal’ some time. I just feel that we cannot commit to more than we already did.” “Ok guys,” continued the Product Owner, “I believe you were honest with the estimations and I think that this is a fine velocity if you meet those commitments with your definition of done. I just can’t figure out this difference and it would be difficult for me to explain this to the stakeholders.” It was good timing for Marianne to do some facilitation work. “The way I see it,” she said, “we have a problem with the measurement unit. The Product Owner is satisfied with the features to be developed in this Sprint, but somehow user stories measured in hours don’t provide the real information, correct? Furthermore, this difference in time is causing confusion. If developer hours cannot linearly correlate with real time, why don’t we say points, not hours? After a few Sprints, we will be better in our estimations in these points, correct? And there will be no confusion with working hours and time. After a few Sprints, we will know our velocity in these points and will have more experience in estimating work. Stakeholders will get their graphics in these points and will be able to monitor progress daily. What do you think?” The Product Owner was delighted with this idea, knowing that he’d be able to show diagrams to the stakeholders in real time, and the team was relieved from the pressure they felt after Product Owner’s speech. Marianne scored her first small victory helping her team to overcome its first impediment and potential conflict. After a few Sprints, they got used to estimations in user story points, so it came naturally to them.

I hope that you enjoyed these real Scrum stories and that you can recognize some of the situations in your everyday Scrum practice. Please comment on them and comment on how you would deal with these situations.

Ideas for splitting Epics into User Stories

Ideas for splitting Epics into User Stories

Remember you are looking to develop slices of the business opportunity the produces valuable working software with the potential to generate feedback from users. Sometimes the story slices are not deliverable to end-users but they generate value from the learning gained in producing them. They should all result in testable and demonstrable software. Consider applying the XP principle DTSTTCPW (“Do The Simplest Thing That Could Possibly Work”)

Consider the following approaches:

What are the visual elements that must be there or can be deferred?

  • You can make a story per viewing steps on a user journey.
  • You can make a story per enabled elements of an input screen.
  • You can make a simple (not pretty) UI.
  • You can make  a command line interface.

What scenarios are in scope for acceptance criteria?

  • You can work with a subset of the user scenarios.
  • You can defer conditional steps to other stories.
  • You can defer data validation.
  • You can defer error handling.

What architecture decision or constraints that can be deferred?

  • You can defer optimization of performance.
  • You can defer internationalization
  • You can defer working on different platforms/devices
  • You can defer handling large volumes of data.
  • You can hard-code data rather than getting from the real source
  • You can stub out components.

This is not an exhaustive list! Be creative in your story splitting approach.

Practical Exercise

Concept: Crowdsource your wedding photos
Invite guests to contribute and view collected photos from event

Benefits: personal photos – longer timeline including build up to big day – cheaper

Costs: web hosting, storage, charging model 5p per upload, 10 per published photo

Challenges: privacy, participation, selecting

Personas: Kim anxious bride, Geoff non-techie guest, Alex always-on-social media mate.


Here are some headline “Epic” stories:

  • Happy couple: Invite guests to contribute photos
  • Guests: Upload photos
  • Happy couple: Select photo set to share
  • Guests: Add information about photos
  • Guests: View photos


  • Get into groups of 2-3 people
  • Grab some index cards
  • Consider one epic story
  • Write smaller stories, one per card
  • Objective: as many small story cards as you can
  • Share one small story with the group at the end

Note: Taken from Rachel Davies, 2014 Agile Adria event

How to Challenge Your Team & Take It to the Next Level

How to Challenge Your Team & Take It to the Next Level

Following are the steps the team took to change this endemic challenge of focusing on what they could not change. Note step 7. All of the steps are critical in the process, and step 7 is the one that will take your team to the next level – it is Follow-Up – and it will ensure that the change sticks!

1. Ask all members of the team to confidentially record their individual answers to two questions: (1) “On a 1 to 10 scale (with 10 being ideal), how well are we doing in terms of working together as a team?” and (2) “On a 1 to 10 scale, how well do we need to be doing in terms of working together as a team?”

2. Have a team member calculate the results. Discuss the results with the team. If the team members believe that the gap between current effectiveness and needed effectiveness indicates the need for team building, proceed to the next step in the process.

3. Ask the team members, “If every team member could change two key behaviors that would help us close the gap between where we are and where we want to be, which two behaviors we all should try to change?” Have each team member record his or her selected behaviors on flip charts.

4. Help team members prioritize all the behaviors on the charts (many will be the same or similar) and (using consensus) determine the most important behavior to change (for all team members).

5. Have each team member hold a one-on-one dialogue with all other team members. During the dialogues each member will request that his or her colleague suggest two areas for personal behavioral change (other than the one already agreed on above) that will help the team close the gap between where we are and where we want to be.

6. Let each team member review his or her list of suggested behavioral changes and choose the one that seems to be the most important. Have all team members then announce their one key behavior for personal change to the team.

7. Encourage all team members to ask for brief (five-minute), monthly three question “suggestions for the future” from all other team members to help increase their effectiveness in demonstrating 1) the one key behavior common to all team members, 2) the one key personal behavior generated from team member input, and 3) overall effective behavior as a team member.

8. Conduct a mini-survey, follow-up process in approximately six months. From the mini-survey each team member will receive confidential feedback from all other team members on his or her perceived change in effectiveness. This survey will include the one common behavioral item, the one personal behavioral item, and the overall team member item. A final question can gauge the level of follow-up – so that team members can see the connection between their level of follow-up and their increased effectiveness.

This process works because it is highly focused, includes disciplined feedback and follow-up, doesn’t waste time, and causes participants to focus on self-improvement.

Let me close with a challenge to you (the reader) as a team leader. Try it! The “downside” is very low. The process takes little time and the first mini-survey will quickly show whether progress is being made. The “upside” can be very high. As effective teamwork becomes more and more important, the brief amount of time that you invest in this process may produce a great return for your team and an even greater return for your organization.

Originally from:, Author: Marshall Goldsmith