Scrum Components: User Stories

The primary method of communication used by Product Owners to convey requirements to the scrum team are User Stories, which in my opinion, are the single most important component in SCRUM.  They express desired end-user functionality, clarify and facilitate the execution of necessary steps to accomplish early and continuous delivery of value and attain customer satisfaction.  User stories are how the Product Owner (voice of the customer)  expresses himself to the SCRUM team  during the kick-off meeting adding them to the Product Backlog. The Product Owner is responsible for the creation and management of the user stories.

User stories when originally defined are goal, value or user oriented and simply stated can encompass large generalities, these ‘epics’ (which can be part of larger ‘themes’) are then decomposed into smaller stories and finally ‘Tasks’ that are completed throughout the life of the project.  I will spend more time on the decomposition of user stories along with the estimation and completion of tasks in future blogs.

There is some variety in the formats used to define user stories but they all follow the general template that answers: Who, What and Why as  shown in the following template:   As a _____ I want ____ so that ____,   i.e. As a Mortgage Broker, I want to be able to reach decision makers on a mobile device, so that I can provide them with the most updated information.

Keep in mind that as requirements change (due to economic conditions, competitive conditions, etc) and new User Stories can be added to the Product Backlog by the Product Owner.

In a co-located center, User stories are generally written out by hand and posted on wall-boards for everyone on the team to see, make decisions on -and while off-the-shelf software products allow similar functionality, in my opinion, the communal room approach is the best method for team communication during Daily Stand-Up, Sprint/Scrum or Backlog Grooming sessions.

If the user story is prioritized, decomposed and time estimated, only those tasks meeting the team ‘velocity value’ are moved into the ‘work-in-progress’ column of the Product Backlog and into the Sprint Backlog for discussion at the next Sprint Planning Meeting.


About Frank:

A credentialed IT Security Professional, Frank is a Project Manager consultant in New York City with extensive experience with Agile and Waterfall projects. He has organized and managed various global projects for the Financial Services, Pharmaceutical and Multi-Media industries providing him with valuable insight that is shared with colleagues and students alike. With over 20 years of industry experience, he has led a number of cross-functional and Agile project teams allowing him opportunities for partnering, team building and facilitating leadership that creates long-lasting relationships and enhances project success

For More Reference visit:


Why Should YOU use SCRUM?

SCRUM is the next big thing in the field of project delivery and is also one of the most popular #Agile methodologies. Let us begin by asking this question “Why do I need #Scrum?”Well, Scrum as a methodology is a good way to manage projects across various industries. Not only is it fast, adaptive, iterative and flexible but it also ensures transparency in communications and creates an environment of collective accountability and continuous progress. To elaborate the above mentioned points, let us have a look at some of the key benefits one can reap by using Scrum methodology to deliver projects.

Adaptability is the very first benefit I want to point out here.  The Scrum principles of Empirical process control and iterative delivery make projects adaptable and open to incorporating change when it occurs. Scrum processes are designed to embrace change. Thus Scrum methodology is best suited to deliver projects in a chaotic and ever changing environment.

A key benefit for stakeholders is that Scrum is “Customer Centric”. Emphasis on business value and having a collaborative approach that includes stakeholders ensures a customer-oriented framework in a Scrum controlled project.

 “Continuous Delivery of Value” is an additional benefit that results from being customer centric. In Scrum, iterative processes enable the continuous delivery of value through the Ship Deliverables process. Each Sprint produces a potentially shippable product, service, or desired result.

“Early Delivery of High Value” is a closely related business benefit of using Scrum. Not only is the delivery of value continuous, the Create Prioritized Product Backlog process ensures that the highest value requirements of the customer are met first.

Both the customer and the project team benefit from “Continuous Feedback.” In Scrum, continuous feedback is provided through the Conduct Daily Standup and Demonstrate and Validate Sprint processes.

Continuous feedback contributes to another key benefit, “Transparency”.  In a Scrum managed project, all information centers such as the Scrumboard and Sprint Burndown Chart are continually displayed and updated, which leads to an open working environment. Sprint Review Meetings demonstrate potentially shippable products to stakeholders, keeping them always informed about the current status and progress of the project.

Transparency leads to another important benefit “High Trust Environment”. The Conduct Daily Standupand Retrospect Sprint processes promote transparency and collaboration. This leads to a high-trust work environment ensuring low friction between employees.

Scrum’s adaptability and transparency create an environment of “Continuous Improvement.” As the project progresses, the deliverables are improved progressively Sprint by Sprint, with changes and improvements being included and managed through the Groom Prioritized Product Backlog process.

Another important benefit is “Sustainable Pace.” Scrum processes are designed such that the people involved can work at a pace that they can sustain indefinitely.

Another benefit of using Scrum is “Efficient Development Process.” In Scrum, it has been observed that time-boxing and minimizing non-essential work leads to higher efficiency levels.

The next benefit is “Motivation”. The Conduct Daily Standup and Retrospect Sprint processes lead to greater levels of motivation among employees.

“Faster Problem Resolution” is another of the important benefits of using Scrum in projects.Collaboration and colocation of cross-functional teams lead to identifying and solving problems more quickly.

The next benefit is Effective Deliverables. The Demonstrate and Validate Sprint process and regular reviews after creation of deliverables ensures delivery of effective outputs to the customer.

The next benefit is “Collective Environment”. The Approve, Estimate, and Commit User Stories process allows team members to take ownership of the project and of their work leading to better quality in Scrum.

“High Velocity” is another important benefit. A collaborative framework enables highly skilled cross-functional teams to achieve their full potential and high velocity. Some of signatories to the Agile Manifesto call this state “hyper-productivity.”

And the last benefit that we will discuss is Scrum’s “Innovative Environment”. The Retrospect Sprint andRetrospect Project processes create an environment of introspection, learning, and adaptability leading to an innovative and creative work environment.

Hope this will answer your question of why you need to use Scrum to deliver your projects.

Note: The Scrum specific terms used in this article are as per the Guide to the Scrum Body of Knowledge (SBOKTM) for more visit:

Who can use Scrum?

Being an Agile approach, Scrum is highly flexible (pun, probably intended); that is, it can be stretched and bent to fit any project’s requirements. It is best suited for projects that require splitting a huge and an unplanned project into manageable chunks of work based on business priorities. As such, it can be used for any project system and by any team.


Scrum really shows its agility in projects that exhibit one or all of the following characteristics:

A. When one is working on a project where scope is changing rapidly and new requirements are emerging every other day, Scrum’s iterative and incremental model of development permits modifications to be made to the project system rapidly and responsively.

B. When there is no consensus on a particular project management approach, the team can adopt Scrum, because its combination of some of the best and most pliable project management principles will help everyone be comfortable.

C. When there is marked ambiguity and indecisiveness on how to get software developed per industry requirements, the increased productivity and decreased risk rate that comes with Scrum makes it the logical choice.

It can certainly be said that Scrum is an ideal project management approach for software development projects. When being swept off your feet with its attractiveness it is good to keep certain points in mind before zeroing in on Scrum as the project management approach for a particular project. First, Scrum is not a method, but an approach, a process tool, for managing the software development activity. Secondly, there are certain core values that must be observed in letter and spirit so that using Scrum can optimize results in better teamwork, enhanced communication, and quicker results.

Note: The Scrum specific terms used in this article are as per the Guide to the Scrum Body of Knowledge (SBOKTM) for more visit:

Why is it important to Develop Epics in Scrum?

In simple terms, epics are user requirements that the Scrum team has to deliver.

What are Epics? User Stories may have to be written constantly throughout the duration of the project. In the initial stages of writing, most User Stories are high-level functionalities. These User Stories are known as Epic(s). Epic(s) are usually too large for teams to complete in a single Sprint. Therefore, they are broken down into smaller User Stories.

User Group Meetings

In the Scrum Methodology, User Group Meetings involve relevant stakeholders, (primarily users or customers of the product), and provide the Scrum Core Team with firsthand information about the expectations of the users. This helps in formulating the Acceptance Criteria for the product, and provides valuable insights for developing Epics. User Group Meetings are vital in the prevention of expensive rework, which may result from lack of clarity regarding expectations and requirements. These meetings also promote buy-in for the project, and create a common understanding among the Scrum Core Team and relevant Stakeholder(s).

Epics are written in the initial stages of the project, when most User Stories are high level functionalities or product descriptions, and requirements are broadly defined. They are large, unrefined User Stories in the Prioritized Product Backlog. Once these Epics come up in the Prioritized Product Backlog for completion in an upcoming Sprint, they are then broken down into smaller, more granular User Stories. These smaller User Stories are generally simple, short, and easy to implement functionalities or blocks of tasks to be completed in a Sprint.

Identified Risks

When creating Epics, new risks may be identified and such Identified Risks form an important output of this stage. These risks contribute to the development of the Prioritized Product Backlog (which could also be referred to as the Risk Adjusted Product Backlog). The Scrum Team members should attempt to identify all risks that could potentially impact the project. Only by looking at the project from different perspectives, using a variety of techniques, can they do this job thoroughly. Risk Identification is done throughout the project and Identified Risks become inputs to several Scrum processes including Create Prioritized Product Backlog, Groom Prioritized Product Backlog, and Demonstrate and Validate Sprint.

Note: The Scrum specific terms used in this article are as per the Guide to the Scrum Body of Knowledge (SBOKTM) for more visit: