Get certified - Transform your world of work today

Close

Scrum in Common Language

A commonsense framework without the uncommon language

5 December 2016


The words we choose to express ourselves and propose ideas matter greatly, not just in how ideas are perceived but in how the listener reacts emotionally and, ultimately, accepts or rejects the proposed ideas. Introducing a new process to a set of stakeholders is just such a case: The words we choose to describe and define the new method can affect whether it is met with comfort, excitement, and understanding or with fear, suspicion, and trepidation. If a new process is presented too abstractly or the change is perceived as too grand, people may become fearful and reluctant, finding the adoption difficult. It is important that we mitigate this fear by proposing process changes in the clearest, least abrasive, and most comfortable manner possible, with careful consideration for the right language.

If you feel that the introduction of Scrum may be met with hesitation or trepidation by management, the development team, customers, or others, try using common language to introduce the ideas, instead of the formal Scrum language found in texts such as the The Scrum Guide. The formal language, though valuable in its own right, can be abstract and confusing to someone who is not already familiar with Scrum. Downplay the formality and use everyday language to carry across the commonsense Scrum concepts, presenting them in a nonabrasive, easy-to-understand manner.
 

Example of common language

Here is one example of a common-language description of Scrum, which does not use any formal Scrum language:
The process starts by organizing all our work into one list and prioritizing each piece based on its value to the business. For each work item — feature requests, technical debt, bug fixes, etc. — we’ll create a separate ticket or notecard, with the acceptance criteria clearly written, giving us a tangible representation of the work that we can use to prioritize items against each other. Make sure to evaluate each item and break it down into the smallest independent deliverable so that we can have a clear view of the overall work ahead of us. Someone will need to assume accountability for the overall prioritization of the work as well as advise on the specifications.

We’ll organize a team of developers (or whomever the team may consist of) who, as a unit, have the skills to complete the prioritized work themselves, from start to finish. It’s best if we’re able to keep the team members constant so that over time they become an increasingly efficient team together.

Once the work is broken down and prioritized, and the team is assembled, we’ll gather together as a group to determine what work we can accomplish over the course of the next two weeks. At this time, the development team can, in addition to discussing the technical details of the work, give each item a rating of complexity from 1 to 5 so that we have a general idea of how much effort each work item requires compared to the others.

When development work is underway, we’ll quickly touch base at the beginning of each day so that everyone on the team can know what everyone else is working on. As well, it’s a chance to call out anything blocking progress so that we can resolve those issues promptly.

At the end of the two weeks, the development team will show their work to the larger base of interested stakeholders, who will see what was accomplished and have an opportunity to give feedback or ask for change requests. After we review the work, I’ll get together with the development team to chat about how the last two weeks went and ask whether there is anything we want to do differently process-wise, going forward, to make things better.

In addition, at the end of the two weeks we’ll quantify the amount of work we completed by summing the 1-to-5 ratings of all the completed items. This will give us a very general estimate of how much work we can expect to complete during the next two weeks.

We will need to keep the prioritization of work up to date, since changes in dependencies and the value to the company of various work items is always in flux. We can schedule, as needed, a regular meeting to make sure that our work priorities are current, acceptance criteria are clear, etc.. If we like, we can invite the development team for early technical feedback.

I’ll keep an eye on things and help facilitate the various meetings. I’ll also make sure to keep the work organized and in front of everyone. As well, I can help the team resolve any blockers they have, and help guide them to be the most effective team possible.

Scrum-speak

This description does not use any of the formal Scrum language, but it gets the point across and touches on many of the core concepts of Scrum. The following maps the description to the more formal Scrum terminology:
  • Backlog: “ . . . organizing all the work into one list and prioritizing each piece based on its value to the business.”
  • Backlog grooming: “ . . . a regular meeting to make sure that our work priorities are current, each item’s acceptance criteria are clear . . . and if we like, we can invite the development team for early technical feedback.”
  • Daily Scrum: “ . . . quickly touch base at the beginning of each day so that everyone on the team can know what everyone else is working on. As well, it’s a chance to call out anything blocking progress so that we can resolve those issues promptly.”
  • Product owner: “ . . . assume accountability for the overall prioritization of the work as well as advise on the specifications.”
  • ScrumMaster: “ . . . keep an eye on things and help facilitate the various meetings . . . make sure to keep the work organized and in front of everyone . . . help the team resolve any blockers they have, and help guide them to be the most effective team possible.”
  • Scrum team: “ . . . a team of developers (or whomever the team may consist of) who, as a unit, have the skills to complete the prioritized work themselves, from start to finish.”
  • Sprint: “ . . . the next two weeks . . . ” “ . . . the last two weeks . . . ”
  • Sprint planning: “ . . . to determine what work we can accomplish over the course of the next two weeks.”
  • Sprint retrospective: “ . . . after we review the work, I'll get together with the development team to chat about how the last two weeks went and ask whether there is anything we want to do differently process-wise, going forward, to make things better.”
  • Sprint review: “At the end of the two weeks, the development team will show their work to the larger base of interested stakeholders, who will see what was accomplished and have an opportunity to give feedback or ask for change requests.”
  • Stories: “ . . . for each work item — feature requests, technical debt, bug fixes, etc. — we’ll create a separate ticket or notecard, with the acceptance criteria clearly written, giving us a tangible representation of the work that we can use to prioritize items against each other.”
  • Story points: “ . . . give each item a rating of complexity from 1 to 5 so that we have a general idea of how much effort each request requires compared to the others.”
  • Velocity: “ . . . at the end of the two weeks we’ll quantify the amount of work we completed by summing the 1-to-5 ratings of all the completed items. This will give us a very general estimate of how much work we can expect to complete during the next two weeks.”
If you feel that introducing Scrum to your company or stakeholders could be met with trepidation and reluctance, don't get overly abstract, and don't overplay the complexity of this otherwise simple-to-understand, highly beneficial framework. It may hinder your cause to introduce this commonsense method with uncommon language. On the other hand, making some of the changes suggested above is one means to provide a more accessible introduction and pave the way for a positive perception of the changes you propose. Scrum language can be introduced later, after the concepts are understood. Using more common descriptions at first will help everyone feel more comfortable with the road ahead.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (8 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe