What is Scrum and What isn't

To maintain consistency, we should follow the standard from Scrum.org when talking about this topic.

Thanks Diane and Christian from PwC Digital , and most content from this article come from their workshops.

What is Scrum? A Framework for agility

What is scrum? The direct answer is : Scrum is a type of methodology. In this article, we will talk about scrum works as an agile framework for developing, delivering, and sustaining complex products.

Basically, scrum is an type of approach to archive agility in a sense. The word agile was in ‘Manifesto for agile software development’ , which will be explained in another article, What is DevOps and what isn’t . In the background of such purpose of agile development, delivering and sustaining software, we have a type of framework called Scrum, which will teach us how to archive this in details. Nowadays , many big company tends to implement such development pattern to improve the efficiency of delivery.

Notice that scrum is just a methodology, so everyone can modify specific approaches below to adapt to real conditions.

Scrum 4 Methodologies(4 OVERs)

1. Ongoing functional software is OVER documents. Software should always be ready for release.
2. Face to face talk is OVER tools. (Communication is the most important).
3. Response to changes is OVER plans. (Software development can't be repeated, we are always facing new problems, and software development is just empiricism).
4. Client is OVER covenant.

How is Scrum Built? Scrum team(s)

Structure

The basic unit of scrum is scrum team. Scrum team is made by 3 parts:

Product Owner (PO), Dev team, and Scrum Master(SM)

1. PO: responsible for the product
2. SM: responsible for the team velocity , and the Scrum workflow
3. Dev Team (including QA and dev), responsible for delivery quality

However, there may be other roles in dev team which will vary from the project, here is a table to describe what they do:

Scrum team vs Developers team

A scrum usually contain specialists from different areas and backgrounds. For example, frond-end programmer and back-end programmer, and PO, BA with non-development background will all be in same team, and share responsibility. Unlike traditional pattern, where we have a PM as a PO-like manager, who talks all responsibility and full right to control the dev team, and we have BE team & FE team for developing, QA team for testing, and BA team to check requirement. In this pattern, each team is organized by the type of their works , and they actually do not need to care if other teams are working fine.

[1] PO’s job is to have frequent talk with BA and client. From client, he need to know what is needed, and what does client want. From BA, he need to know the status of current development, and how many features/bugs can be done/fixed in what time.

[2] SM’s job is to ensure scrum is real. A SM will original all kinds of conferences, and make sure everyone follows scrum, and do their jobs. Actually if scrum team make bad software, SM won’t take that responsibility. But if scrum failed, like conference failed, or spint goal failed, then SM was responsible for this.

[3] BA’s job is to have frequent talk with dev team and PO, also, BA needs to quantify requirements from PO into User Stories . BA should keep watch dev team, to make the dev status of each User Story, and make adjustment with dev team and PO. e.g. If a user story is too complex, or impossible to implement in current technology, BA will receive feedback from dev team, and talk with PO about this.

[4] Tech Leader can handle tech advisory from BA, explain complexity to client. Also, Tech leader can assign user stories to members when a sprint starts, while members can also have a talk to choose tasks on their own.

More than one Scrum team

When there's 2 or more Scrum team for different modules from one big project, we tends to use another similar management process called 'Nexus', you can learn about more in next part of this article.

How does Scrum team work? Sprints

Sprint structure

Sprints is a short-team development period with fixed time length.

A sprint contains these related things: (Not every event has to exist)

Among all the meetings, SM will use timebox to control time. One sprint can be described by this image:

Sprint estimation

1. Every user story will get a estimation with ‘Points’. The value of points must be in Fibonacci sequence, so we can break it down.

   In high level estimation, BA will ‘guess’ how many points will be in next sprints. And multiple the result by 120%. (20% for redundancy). This will help BA to share tasks to each sprint equally.

2. In low level estimation,dev team will check each user story, and give it a specific point estimation:

   For example, if a user story has 5 points. It means the complexity is equal to a 2-point story plus a 3-point story.

   Everyone in dev team should estimate every user story and give their judgement of point

3. After estimation, BA get the total points of this sprint. And SM draw a straight line in burn-down chart. On the last day the rest point should be 0.

   Once the current progress curve is higher/lower than this line, SM will know that current progress is behind/ahead estimations.

Sprint features

• In theory, anyone can’t change, modify the task, goal, or requirement of a sprint.

• Only SM can cancel a sprint, but it’s(such cases) very rare.

• Dev team can chose user story themselves, while tech leader can also assign a story to someone

• If a story needs teamwork, it will be several “sub-tasks” inside.(e.g. One for FE and another for BE, and additional one for BA)

• User story must be set to based on ‘User’, to create two stories for frond-end and back-end is FORBIDDEN

Basic Task Unit: User Story

User Story is the smallest task for scrum team. A user story is the description of a serious of operations from a type of end user, written by BA.

After PO get a change in requirement, BA will write corresponding User Story, and put it in Sprint Backlog. In sprint planning, scrum team will decide which sprint will handle this User Story. Thus, typically , a User Story will have these states:

• In backlog
• Ready to estimate
• Ready to develop
• In progress
• Ready for QA
• In QA
• Closed

We generally use Kanban to overwatch all User Stories like this:

In a sprint, there will be several user stories arranged, and if one user story is too complex, or PO is informed that client do not want this anymore, this user story can be shifted to next sprint or repealed during this sprint.

Sprints vs Version

Actually, sprints is just like a new version in development environment. When a sprint closed, the product in env will be merged with this next version.

However, not every sprint will be released to client.

Nexus: Scrums of Scrum

Nexus is the system to manage multiple scrum teams. The form is usually the Nexus sprint planning

Nexus is a complex system, you can view its guide from THE NEXUS™ GUIDE

Scrum necessary meetings

If you are confused about the events above, just understand which meetings should be hold.

PDCA Theory : Plan,Do,Check,Act

1. Requirement refinement meetings

   Get user stories ready.

2. Sprint planning meetings

   Confirm the goal of this sprint. Once the goal is confirmed, the goal can not be changed. In rare cases, when the goal is no longer valuable due to changes of market, the goal can be modified. Dev teams should avoid new stories to come in, if it's a must-do, then other stories should be removed to keep velocity.

3. Daily Scrum

4. Sprint Demo

   Show the value deliveried to PO.

5. Sprint Retro

   'How to imporve our vecolity?', asked by SM.

Scrum necessay components

1. Product backlog (vision) Anyone can add items in this backlog, and PO will select what should be done

2. Sprint backlog(plan) TODOs in this sprint Once a story was in sprint backlog, dev teams will be responsible for this.

3. Product increment Demo ready to show to PO.

Why Scrum?

Scrum provides many existed approach to help agile development and delivery.

You can follow these resources to learn more about scrum:

• What is Scrum?
• 11 reasons why Scrum is great for developers
• Why Does Scrum Work?

What is not Scrum?

The key of scrum is the pattern of operations in scrum teams. Scrum’s main thought is to let people from different areas be in same team, and share responsibility. For example, if PO does not need to take responsibility for the failure of dev team, this is NOT Scrum.

Another point is that Scrum should be agile, and Scrum team should hold Continuous delivery.

Q&A

Q: Is Scrum useful for every project? In some project, e.g. a project that could be controlled by senior officials and public officials, scrum is not recommended.

Or, in some long-term project with certain goal, like to build a real building, do research in a cutting-edge project, scrum is not recommended.

Or, in some cases that PM pattern performs better.

Q: What’s PO’s job, can PO be a committee?

PO MUST be a single person, otherwise we don’t know which one to follow. PO defines VISION. prototype, and road-map.

Q: What’s dev team(with BA)’s job?

They make the product backlog (sprint backlog), we sometimes call it PBL. PBL has priority and estimated points.

Q: What time should a sprint last?

1-3 Week(s), generally 2 weeks. Dev team must complete kick off, development and test during this time.

Q: What if dev team member is distributed?

To use PMP may be a better choice. Because we have a powerful PM to control them._

Q: It seems like SM do not engage in development, can we remove SM?

*NO. SM must quantify team and calculate VELOCITY to make it possible to improve. And they have to control meetings*