Scrum is a subset of Agile. It is a lightweight process framework for agile development, and the most widely-used one.

A ‘process framework’ is a particular set of practices that must be followed in order for a process to be consistent with the framework. (For example, the Scrum process framework requires the use of development cycles called Sprints, the XP framework requires pair programming, and so forth.)

‘Lightweight’ means that the overhead of the process is kept as small as possible, to maximize the amount of productive time available for getting useful work done.

Scrum Ingredients

Artifacts: things (kanban board, product backlog)

Roles: what people do

Events: types of meetings

Priority

Transparency:

Of work in progress;

On product backlog (work to do)

Meetings: Only 5 easy meetings

Simplicity: 3 types of roles in the team

Fixed timelines: iterations, sprints.

Strong product vision (evolution);

Flexible scope in the iterations

Are you ready to see the overview of Scrum?

Team characteristics

Ideal team size: 7 (+/- 2): link to research on team size

Collocation: team in same room

Dedicated team members: work mostly/only with this team

Cross-functional: team members have different backgrounds and should be able to do each other’s work

Scrum Artifacts / Artefacts

Product Backlog

Sprint Backlog

Burn-down chart

User Stories

And (possibly):

Release burn-up

Scrum: Artifacts: Product Backlog

List of User Stories.

The requirements for the product are listed in the Product Backlog.

It is an always changing, dynamically prioritized list of requirements ordered by Business Value.

User stories are part of an Agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.

User stories are actually narrative texts that describe an interaction of the user and the system, focusing on the value a user gains from the system. A true user story is a metaphor for the work being done. It is not a highly documented requirement but rather a reminder to collaborate about the topic of the user story—in other words in agile development (good agile at least), the documentation is secondary to the collaboration. User stories aren’t agile in and of themselves. Instead, their underlying agile values—collaboration and just-in-time definition—make user stories a good agile tool. Formality is specifically removed from the mix and specification of the user story is pushed as late as possible.

More about User Stories

CCC (mnemonic)

Card: we need an item: digital or a card on a wall.

Conversation: the team needs to talk about the card

Confirmation: the team needs to confirm that we understand the item.

INVEST (mnemonic)

Independent: self-contained, no inherent dependency on another PBI

Negotiable: up until they are part of an iteration (sprint) they can always be changed and rewritten.

Valuable: a User Story must deliver value to the client / user / customer/stakeholder(s)

Estimable: Team must be able to estimate the size of a User Story

Small: small enough to plan / task / prioritize with a certain level of certainty; <50% of effort.

Testable: must provide necessary information to make test development possible.

A short consideration about the bugs in Agile (for Scrum teams): A team works together on a user story. And the definition of that being done includes that all development work is done and that all the issues or problems have been fixed before ending the sprint. However sometimes a user story can be interpreted in different ways. Or sometimes teams procrastinate in fixing bugs and bring in new work. They falsely consider the earlier work done. But there’s a big beast under water…

Situation: the product as shown is not good for the Product Owner

Possible causes:1. The user story was not clear enough for the developer: The developer thinks he understands the story but the BA has a different idea about the same.Solution: create a new story, add it to the backlog and prioritize it so that it comes in the next sprint (or in the same sprint in exceptional cases). The story should have its own title, description, acceptance criteria and should also be demoed – like all the stories.

2. The story is clear but a mistake is made and not seen by the developer or one of the peer developers (peer review is important).Solution: Two options, create a bug and add it to top of the product backlog, raise it during the call, find a developer who is available to volunteer and implement the fix. Take it offline in a separate call. Or create a new user story instead. Which comes across nicer. It’s a fine line sometimes between: “YOU MESSED UP, I NEED A FIX NOW!” and “no worries mate, you can fix that later… whenever yeah”

3. The developer made the right code but broke another set of codeSolution: Make sure that continuously, in every sprint, a part of the bandwidth of work is allocated to regression testing. Developers checking whether the existing software, that was made earlier still functions. Make sure that you have this in place if you do not want to end up in a jungle of something called technical debt.

Another consideration
Some teams bulk up so many bugs, while they continue to produce new software. In all cases, me and my peers advise to stop pulling new work but fix the issues at hand first. This might sound simple, but if you have the drive of a deadline coming close it could feel like you should try and create more software first. Which means: you are on a death march.

Story Points are easier to understand and work with than most people think.

What are story points?A Story point is a arbitrary measure used by Scrum teams. This is used to measure the effort required to implement a story. In simple terms its a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort.

So teams size on a piece of work. Is it a lot of work? Is it complicated? Is there uncertainty?

So three elements:

Complexity

Unknowns / uncertainty

Effort

Methods:

T-Shirt sizing ( Large, Medium, Small)

Story Points (modified Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100)

Get goingScrum Master / Team Lead: During a session where the work is discussed, talk about a user story.

Ingredients

Development team

Product Owner

Scrum Master

Poker cards

User stories / Stickies with stories

Ask the developers to think (NOT to talk) about how complicated it is for a moment. Bring in Scrum Poker cards or get a set of yellow stickies. And write per sticky the Fibonacci sequence (1,2,3,5,8,13). Or small pieces of paper will do too.

Ask the developers to select a card (picking a number) and hold it to themselves. Now when all the people have picked one, ask the developer to open their cards at the same time.

What if I am not in the same room (collocated)?Ideally you are. But if you aren’t, or working remotely for the day; use an online tool, like planningpoker.com made by Agile guru’s and free up-to 10 people.

Voting tricksThere’s some very interesting psychological trick behind the voting with closed cards. The surprise is great, instead of people influencing each other. Some people have bigger ego’s than the others. By not influencing each other the outliers who are more junior – for example – learn a lot from their peers because it always results in a conversation about the work; which evens out problems, reduces unknown elements of that work and so on.

Tricks from an Agile Coach
Some people will always try to quantify a point or a S/M/L size of a User Story into days, hours. People have learned for decades that when they hear the word Effort, that it relates to period of time (hours, man days, weeks). If that’s the case, try to forget the amount of effort you think it takes to finish the work. Instead ask the people to vote for just the complexity.

During the refinement sessions we are preparing the place holder stories in the sprint backlog to get to this definition. Only if they are ready, we can bring them in to a new sprint.

User story has:

A description (As a X, I want Y, So that I Z).

Acceptance criteria (important for definition of done).

Story points.

How to demo.

So that’s equal for all the types of user stories, may it be a support task with uncertainties in terms of the actual work, or for JIT execution or any other possible work-related task.

Definition of Done (DoD) for a user story (feature)

This definition marks the point where a story is really Done. Now this seems like a cliché but there are many discussions on wether something is really done or not. In order to set the criteria for the DoD we use the acceptance criteria in the user story. This functions like a check-list; if all are checked the story is done.

And when all the user stories are conform the DoD we define the DoD for the sprint.