Scrum Institute, Scrum Framework Episode #10 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org

You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play.

Listen to Scrum Institute Podcast on Apple
Listen to Scrum Institute Podcast on Google Play
Listen to Scrum Institute Podcast on Spotify
Listen to Scrum Institute Podcast on Listen Notes
Listen to Scrum Institute Podcast on Castbox

What Is User Story In The Scrum Framework? This Might Surprise You!

The entries in the Scrum Product Backlog are often written in the form of User Stories. A User Story tells a short story about the requirements of someone while he or she is using the software product we are building. 

It has a name, a brief narrative, and acceptance criteria for the story to be counted as completed. The advantage of user stories is that they precisely focus on what the user needs and wants without going into the details on how to achieve them. How to achieve them will be the job of the Scrum team as a later stage, 

There are different recommendations on how to define User stories. A well known and reliable template is: 

As an [actor], I [want|must] [action] so that [achievement] 

Or in a shorter version:
As an [actor], I [want|must] [achievement] 

The Actor is the owner of the user story. That is often a user, but it is advisable to be more specific. By using particular actors such as an administrator, logged in customer, or unauthenticated visitor or so on, user stories become distinctive. So they set requirements into a proper context everyone can understand.

The Action is what the Actor wants to do. If it is a mandatory requirement, it can be prefixed as must. Otherwise, it’s prefixed as want.

The Achievement is what the Actor wants to achieve by performing the Action. That’s the Actor’s envisioned business result or a functional technical component that emerges once the Action is completed.

How To Estimate Effort For Stories In The Scrum Framework? This Might Surprise You!

All user stories within the Scrum Product Backlog have to be estimated to allow the Scrum Product Owner to prioritize them and plan releases. That means the Scrum Product Owner needs a reliable assessment of how much the delivery of each user story will take. 

Nevertheless, it is recommended that the Scrum Product Owner does not interfere with the estimations that the Scrum Team performs. So the Scrum Team delivers its estimates without feeling any pressure from the Scrum Product Owner.

The Scrum Framework itself does not prescribe a way for the Scrum Teams to estimate their work. The teams who rely on the Scrum Framework do not deliver their estimates of user stories based on time or person-day units. Instead, they provide their estimates by using more abstract metrics to compare and qualify the effort required to deliver the user stories.

Common estimation methods include: 

• Numeric sizing (1 through 10),
• T-shirt sizes (XS, S, M, L, XL, XXL, XXXL), or
• the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, etc)

An Example User story

The Scrum Team members must share a common understanding and consensus of the unit of estimations they use so that every member of the team feels and acts comfortable with it. 

Planning Poker® / Scrum Poker

One commonly used method for the estimation process is to play Planning Poker® (also called Scrum Poker). 

When using Planning Poker®, the social proof influence among the Scrum Team members are minimal. Therefore, the Scrum Team produces more accurate estimation results. 

What you need to play Planning Poker® game is straightforward: 

• The list of features to be estimated
• Decks of numbered cards.

A typical deck has cards showing the Fibonacci sequence, including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Other similar progressions are also possible. The reason for using the Fibonacci sequence is to reflect the uncertainty in estimating larger items. It would be a waste of time to discuss if a user story should have a size of 19, 20 or 21. And yet, it’s relatively easier to decide if the user story fits better to the size 13 or 21.

A high estimate could mean that the Scrum Team members have not very well understood the user story yet. So they can attempt to secure extra capacity for contingency before their commitment to this user story. Alternatively, that could also mean that the user story should be broken down into multiple smaller user stories.Scrum teams can usually estimate smaller and clearer user stories with higher confidence.

Finally, the Scrum Team plays Planning Poker® by adhering the following steps: 

• The Scrum Product Owner presents the story to be estimated. The Scrum Team asks questions, and the Scrum Product Owner articulates the user story in more detail. If the Scrum Team has to assess many user stories, estimates can be time-boxed in a way that the Scrum Team does not spend more than a few minutes for each user story. If the team cannot still estimate a user story in a given time-box, then this could be a signal to which the Scrum Product Owner needs to pay attention. This signal indicates that either the end-user requirement or the user story or both of them are not clear enough, so they need to be rewritten.
• Each member of the Scrum Team privately chooses the card representing the estimation.
• After everyone has selected a card, all selections are revealed.
• People with high and low estimates are asked to explain their assessment because they may have thought something that the majority of the Scrum Team members have been unable to see.
• Another estimation is done for this particular user story until the team reaches a consensus for an estimate.
• The Scrum Team repeats the game until they estimate all user stories. 

Planning Poker® is a registered trademark of Mountain Goat Software, LLC.

What Is The Definition Of Done In The Scrum Framework? This Might Surprise You!

In the Scrum framework, the factors which define when a feature is complete and when it meets the required quality standards are set by Definition of Done (DoD). 

As it was clarified before in this material, DoDs specify the expected outcome in terms of functional and non-functional requirements, design, coding, unit testing, end-user validations, documentation, and so on. DoDs are defined in the levels of both user stories and tasks. 

DoDs of user stories focus on functional and non-functional client requirements, whereas DoDs of tasks focus on the desired working activities from the Scrum Team members.

The Scrum Team is not allowed to close the user stories, and obviously, the tasks that do not fulfill their DoDs. Definition of Done (DoD) is used to decide whether a User Story from the Sprint Backlog is complete or not. DoD is a comprehensive checklist of required activities to ensure that only truly completed features are delivered, not only in terms of functionality but in terms of quality as well. The norms which a Scrum Team uses to define DoDs may vary from one team to another, but it must be consistent within a given Scrum Team.

There are usually different DoDs at various levels: 

• DoD for a Project/Product (In the project goals)
• DoD for a Release (In the release goals)
• DoD for a Sprint (In the sprint goals)
• DoD for a User Story (In the User Story)
• Dod for Tasks (In the task) 

One more essential thing to keep in mind here is that a DoD is neither static nor indisputable. During the course of a project, a release, or a sprint, a DoD can be challenged by anyone from the Scrum team or other business and IT stakeholders. As long as the proposed changes of a DoD makes sense and they’re brought up to bring the project to success, the Scrum Team and the Scrum Product Owner should be open minded to listen to those proposals and implement them when and where necessary.