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

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)
How To Estimate Effort For Stories In The Scrum Framework? This Might Surprise You!
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.

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

How Does The Scrum Framework Work Without A Project Manager? This Might Surprise You!

In a traditional project, typically, a Product Manager defines the requirements. Then the Product Manager delegates the realization to a Project Manager. Afterward, the Project Manager coordinates all activities needed to deliver the requirements of the project.

The Scrum Framework does not define a “Project Manager” role in the classical sense.

And yet, the tasks of this role are still required to deliver a project successfully. Within the Scrum Framework, the responsibilities of a Project Manager are distributed over the functions of the Scrum Product Owner and the Scrum Master.

The definition of the role and responsibilities of the Scrum Product Owner takes possible conflicts that may arise between the Product Owner and the Project Manager into account. Decisions about functionality, release planning, and budgeting can be made much more comfortable, quicker and better if one person is responsible for the execution, controlling, and documentation of those activities. Otherwise, there would always be a constant tension between the Scrum Product Owner (not responsible for the project) and the Project Manager (not responsible for the execution of work).

The goal of any reliable process should be to avoid this potential conflict that impacts the functional and tactical administration of the work that the Scrum Team performs. And that’s precisely what the Scrum Framework aims to accomplish. Therefore, the typical responsibilities of Project Managers and Product Managers are merged into the Scrum Product Owner role.

Nevertheless, the Scrum Master takes over some responsibilities of a traditional Project Manager. Tracking the tasks in Sprints and facilitating the resolution of impediments are among his duties. Since he or she is part of the Scrum Team, it is much easier and much more efficient to handle such activities directly in the team.

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

What Is The Role Of The Scrum Team? This Might Surprise You!

The Scrum Framework recognizes three roles:

The Product Owner,
The Scrum Team Member,
The Scrum Master.
In addition to other programs it’s providing to its worldwide students, International Scrum Institute™ provides three primary training and certification programs for these three roles.

These programs are namely Scrum Product Owner Accredited Certification™ (SPOAC™), Scrum Team Member Accredited Certification™ (STMAC™), and Scrum Master Accredited Certification™ (SMAC™) .

A proper scrum organization must adequately possess people from all these three skill-sets. That’s particularly essential to succeed with the scrum software development framework.

None of these roles is indispensable and irreplaceable. They cannot be combined with the other scrum roles and functions. Each Scrum Product Owner typically works together with one scrum team. Each Scrum Team has its own Scrum Master, and each Scrum Master cares and works with one single Scrum Team.

Please don’t underestimate the importance of understanding the purpose and function of these roles and employing them with adequate talents.

Many times we observed that the root cause of difficulties of a scrum team is either because these roles are not understood or they don’t employ the right people.

Each of these roles has a defined set of responsibilities. Only if the owners of these roles fulfil these responsibilities, closely interact, collaborate, and work together, they can finish a Scrum project successfully.

What Is The Role Of The Scrum Team? This Might Surprise You!
Scrum Roles & Stakeholders

The Scrum Team

Within the Scrum Framework, dedicated Scrum Teams do all work delivered to the business clients. A Scrum Team is a collection of individuals working together to provide the requested and committed product increments.

To work effectively, it is essential for a Scrum Team that everyone within the team:

Embraces values of the Scrum Framework such as Courage, Focus, Commitment, Respect, and Openness,
Adheres the same norms and rules,
Follows the common goal, which wires them to both IT and business outcomes.
When setting up a new Scrum Team, you always need to keep in mind that no new team will deliver with the highest possible performance right from the beginning. After setting up the team, it has to go through certain phases as described by the Tuckman-Model: Forming, Storming, Norming, Performing.

What Is The Role Of The Scrum Team? This Might Surprise You!
Tuckman’s Stages of Team Development

How long it takes until the Scrum Team reaches the Performing Phase varies from team to team. Hiring good basketball players for the same club will not make a good basketball team as soon as they start to play together. They first need to learn and adapt their playing styles, their strengths and weaknesses to assist each other, and to play in harmony. Scrum teams are not that different. Therefore, it’s vital to keep in mind that it usually takes about 3 to 5 Sprints until the team becomes mature enough to deliver its results effectively and predictably.

Characteristics of a Scrum Team

Scrum Teams have the following characteristics:

Team members share the same norms and rules,
The Scrum team as a whole is accountable for the delivery,
The Scrum Team is empowered,
The Scrum Team is working as autonomous as it is possible,
The Scrum Team is self-organizing,
The skills within the Scrum team are balanced,
A core Scrum Team is small and has no sub-teams,
The Scrum Team members are dedicated to their teams with 100% capacity,
Scrum Team members are collocated, and they ideally share the same room.
Rules & Norms

The environment, business, IT, and geographical ecosystem of Scrum Teams invisibly define some of the norms the teams follow. And yet, to become a truly successful Scrum Team, some rules and norms should be explicitly developed and exercised during the Norming phase.

These common standards are essential, and they can’t be overemphasized to deliver smooth gameplay, IT, and business results. Otherwise, the Scrum Team members would have to continually switch back and forth between different value systems and rule sets, and they waste their valuable time. Just a few examples of such norms and rules are:

The goal, scope, duration, location, participants and outcomes of Scrum Rituals (Events),
Required level of details to write clear, concise and unmistakable Definition Of Dones (DoDs),
Guidelines to prioritize and estimate user stories and tasks,
Guidelines, procedures and the level of details to create living documents,
Tools to use and tools not to use (remember, sometimes less is more),
Coding standards,
Tools and guidelines to build/perform manual/automated tests and ensure quality,
The process to resolve bugs,
The process to handle change requests,
The process to prepare to product increment demonstrations during Sprint Review Meetings,
The process to handle the outcomes of each Scrum Ritual (Event),
Frequency, depth, and duration of Backlog Refinement Meetings.
Accountability

The Scrum Team as a whole is responsible for delivering the committed user stories in time and with the highest possible quality.

A good result or a failure is never attributed to a single team member but always the result of the Scrum Team.

Empowerment & Self-organization

The Scrum Team has to be empowered to define

What the team commits to deliver at the end of the Sprint,
How the committed user stories will be broken down into tasks,
Who will perform a specific task and in which order the tasks are implemented.
Only if the Scrum Team is empowered to decide these and similar internal decisions, the team members will work with higher performance and motivation for the interest of their client stakeholders.

Balanced set of skills

Each Individual within the Scrum Team will most certainly have specialized skills, focus, and personal preference of interests. However, to achieve the best possible performance, your Scrum Team needs to have a balanced set of skills. Only then the Scrum Team will be able to deal with the ever-changing IT and business challenges, and they can act as autonomous as it is possible.

That means a Scrum Team should be multidisciplinary (designers, developers, testers, architects, etc.) right from the beginning. On the other hand, this also means that each team member should learn a little bit from each other’s specialization. For instance, to be able to finish a committed user story until the end of the Sprint, a developer should willingly write and execute tests, and consult the tester whenever necessary.

The roles of the Scrum Team members are not compartmentalized like the architect, the developer, the tester, and so on. They all share the same title, “Scrum Team Member” regardless of their core personal competencies.

Size of the Scrum Team

Scrum Teams are small. The ideal size is 7 +/- 2 people.

Note that if the Scrum Team contains more than nine members, your team will most probably suffer due to excessive overhead of alignment and communication. And yet, there is no one size fits all answer. Your Scrum Teams may still productively function even if they have less than five or more than nine members.

The only way to find this out is to test, learn, and adapt. If you find out that a team of 13 people cannot perform well enough, then these Scrum Teams need to be split into two teams. These Scrum Teams should closely align, and they correlate their goals and user stories. Besides that, they work independently.

Collocation

To minimize unnecessary communication overhead, each Scrum Team should be collocated. If the work has to spread over multiple geographical locations, independent Scrum Teams need to be created. These teams need to align and correlate their goals and user stories.

Responsibilities of the Scrum Team

The Scrum Team has specific responsibilities they need to fulfill:

They have to breakdown the user stories, create tasks, define priorities and estimates, and they self-organize the implementation. In other words, they have to create, process, and deliver the Sprint Backlog.
They have to perform Daily Scrum Meetings.
They have to ensure that at the end of the Sprint, potentially shippable product increment is delivered and demonstrated.
They have to update the status and the remaining work efforts for their tasks to allow the creation of a Sprint Burndown Diagram.

What Is The Role Of The Scrum Master? This Might Surprise You!

The Scrum Master serves all participants of a Scrum Project and the external stakeholders to comprehend and apply the Scrum Framework correctly.

He or she supports the Scrum Team to execute the Scrum Framework successfully and contributes them to improve their productivity and performance continuously.

The role of the Scrum Master is to establish the Scrum Process in its organization, the new way of thinking and acting.

Furthermore, the Scrum Master acts as a change agent. He or she coaches the team to develop new team norms and standards. The Scrum Master has its desk somewhere very close to the rest of the scrum team.

Essential tasks of a Scrum Master owner are:

To establish the Scrum Framework in his or her business and IT ecosystem,
To act as a change agent and support the adaptation of existing processes to maximize productivity of the Scrum Team.
To coach the Scrum Team to understand and live the values of the Scrum Framework,
To ensure efficient and close collaboration between the Scrum Product Owner and the Scrum Team,
To remove impediments which hinder the continuity of work,
To lead progress of work by serving,
To moderate the Scrum Rituals (Scrum Events).
To guard the Scrum Team from external interference and interruptions while the team does work it has originally committed for a Sprint.
Easily Learn Scrum and Officially Prove Your Know how

To effectively do this work, a Scrum Master needs to possess savvy moderation and coaching skills. He or she needs to be a continuous learner to inspire others to learn, change, and grow.

To learn more about Scrum Master’s duties as a facilitator, I recommend you to have a look at this article: If I had 5 Minutes to explain Scrum Master As a Facilitator.

To learn more about Scrum Master’s duties as a facilitator, I recommend you to have a look at this article: If I had 5 Minutes to explain Scrum Master As a Facilitator.

The Scrum Master is part of the Scrum Team and acts as a servant-leader for the Scrum Team. In the beginning, this will be a full-time job so that the Scrum Master will not be able to contribute to the Sprint results directly. However, after a few Sprints, while the Scrum Team approach to the Performing phase of the Tuckman model, the initial workload as moderator and coach will reduce. So, the Scrum Master could actively contribute to the Sprint goals.

Since there must be trust between the Scrum Master and the Scrum Team members, it can always be a good idea that the Scrum Team chooses its Scrum Master. However, in reality, the management usually imposes who the Scrum Master will be. To get the required trust, the Scrum Master should have no line management responsibility above the Scrum Team members. Otherwise, open communication in the Scrum Team and joint ownership of work and decision-making ability of the Scrum Team can suffer.

Guarding The Scrum Team, Removing Impediments

An essential job of the Scrum Master is to safeguard the Scrum Team from a false sense of urgency. Line management and the Scrum Product Owner often attempt to add unplanned user stories to the Sprint Backlog while the team focuses on the work of a planned Sprint.

However, one of the critical aspects of the Scrum Framework is that all user stories are known and committed only during the Sprint Planning Meetings. The Scrum Team cannot be forced to take over new user stories. The job of the Scrum Master is to ensure that until the next Sprint Planning Meeting, these new user stories are stored in the Scrum Product Backlog.

Alternatively, if the ongoing Sprint does not make any business and/or technical sense to continue, it can be canceled, and a new Sprint can be planned.

Scrum Team members should only concentrate on delivering client value by building potentially shippable product increment. The Scrum Master helps by removing impediments that block or slow down the progress of work.

Examples of removing impediments could be:

To arrange support, resources,
To find missing know how, and
To do hands-on work to help the Scrum Team Members.
Scrum Master as a Change Agent

One of the cornerstones of the Scrum Framework is the continuous improvement through Inspect & Adapt.

The Scrum Master hosts and moderates the Scrum Retrospective Meeting, and his or her job is then to facilitate, control and measure the change of the identified shortcomings.

Facilitation of Scrum Rituals (Event)

The Scrum Framework defines several meetings that have to be organized and facilitated by the Scrum Master:

Scrum Grooming (Backlog Refinement) Meetings,
Sprint Planning Meetings
Daily Scrum Meetings,
Sprint Review Meetings, and
Sprint Retrospective Meetings

What Is The Role Of The Scrum Product Owner? This Might Surprise You!

The Scrum Product Owner is a central role within the Scrum Framework. That role unifies product and project management tasks, and it’s also firmly integrated with software development and delivery.

The product owner’s role is far broader than traditional project management, program manager, or product management roles.

He or she represents the end customers and/or other stakeholders and is responsible for maximizing the value of the product by ensuring that the Scrum Team delivers the right work at the right time. The Scrum Product Owner decides the software requirements provided for a specific software version, and when the software will be released. She represents functional and nonfunctional demands from end-users.

That means that the Scrum Product Owner has to work very closely with the Scrum Team and coordinates their activities over the entire lifecycle of the project. No one else is allowed to impose the Scrum Team to work for a different set of priorities.

Essential tasks of a Scrum Product owner are:

To manage and clarify project requirements,
To guide releases and to ensure return on investment (ROI),
To closely work with the Scrum Team and enable it to deliver the correct work on time,
To manage stakeholders and their expectations,
To manage the Scrum Product Backlog.
The Scrum Product Owner can delegate certain activities (like physically maintaining the Scrum Product Backlog). However, he or she still owns the accountability of his or her tasks.

Managing the Product Backlog

The Scrum Product Owner is the only person allowed to own the contents of the Scrum Product Backlog. That means he or she needs to:

Create, maintain and clearly describe user stories in the Scrum Product Backlog,
Prioritize user stories to accomplish business goals and fulfil the mission of software product,
Ensure that the Scrum Team correctly comprehends and implements the user stories in the Scrum Product Backlog.
Release Management

The Scrum Product Owner is responsible for reaching the project goals. He or she creates and maintains the release plan and decides about deliveries, end-user functions, and the order they need to be delivered. Scrum Product Owners often manage the costs and budget of Scrum Teams too. They collaborate with the Scrum Team members to fine-tune, prioritize, and estimate user stories.

Stakeholder Management

External stakeholders should not directly bring their demands to the Scrum Team members. Instead, the Scrum Product Owner should collect and assess required functionalities with the stakeholders (for instance, with internal clients, representatives of external clients or end-users). The Scrum Product Owner combines, filters and initially prioritize these user stories before they’re discussed them with the rest of the Scrum Team.

Collaboration With The Scrum Team

For a successful project, the Scrum Product Owner and the Scrum Team must work very closely. The Scrum Product Owner is responsible for ensuring that the Scrum Team members are informed and aligned about the aimed goals of software they’re building.

During Sprint Review Meetings, the Scrum Product Owner is responsible for inspecting, accepting, or declining deliverables of the Scrum Team.

What Is The Role Of The Scrum Team Member? This Might Surprise You!

The Scrum Team Members implement the software. They jointly decide the number of requirements that they can undoubtedly deliver during a particular product increment called “Sprint”.

A high-performer scrum team has most of the software engineering skills typically in it. Software developers, architects, testers, database administrators, and team members from all other roles work together.

They jointly build and deliver great software their client is paying for.

Scrum team members do no longer belong to a functional silo of a matrix organization. Developers do no longer belong to software development competence centers, and testers do no longer belong to the software testing competence center, and so on.

Regardless of their past coordinates in the organization, members of a scrum team belong to their particular scrum project.

Now their job is to build the best possible software to deliver the requirements of their scrum product owner.

Characteristics of scrum teams are:

Empowered and Autonomous,
Cross-functional
Self-organized and small
Full-time participants
Working in the same room
One for all, all for one.
It’s an excellent time to remind that the Scrum Team members follow Scrum values persistently.

Courage
Focus
Commitment
Respect
Openness

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

What Can Cause Chaos And Frustration Before The Scrum Framework? This Might Surprise You!

To better understand the impact of the scrum framework to our software engineering practices and businesses, it makes sense to have a look at a day in the life (or a software project in life).

Therefore, I would love to briefly talk about a software project from the past before we adopted the scrum development and software delivery framework in our organizations.

A few days before I wrote these lines, we had lunch with one of my ex-colleagues with whom we used to work together almost 20 years ago.

This gentleman, Marcus has got his scrum master certification and scrum product owner certification from International Scrum Institute™. He currently works as a scrum master for one of the leading software houses in the agile project management software domain.

As a scrum master, Marcus is now in charge of operating an agile scrum team whose scrum team members located in geographically distributed locations around the globe.

During our lunch, Marcus admitted that there are a lot of typical challenges with distributed agile scrum teams. Some of the problems he specifically mentioned related to his software project configuration are:

Differences in working styles among scrum team members,
Timezone differences,
Cultural misfits, and
Language constraints.
Despite these difficulties, Marcus still added that running a software project with the agile scrum process is more fun, productive, and enriching than how we used to work 20 years ago. Compared to days when we used to work without scrum software development and scrum software delivery processes.

Marcus’ statement was indeed a big testimonial for the credit of the scrum framework from a very accomplished and experienced manager, scrum master, and product owner.

Thank you, Marcus!

Then we explained to him one of our past software projects before we used to meet with the scrum framework. I’m sure that many scrum masters would resemble this experience to their previous projects before they’ve gotten their scrum master certifications.

Back in the late 1990s, we were part of a software engineering group to build a smart card-based public key infrastructure. Smart cards securely protected private keys of infrastructure members, associated public keys and their wrapper certifications were openly distributed (as the name public implies).

Back in the day, this was by itself a relatively complex IT project that required multiple interdependent hardware engineering and software engineering teams. We had to do massive amounts of research and development (R&D) to build a fully functional hardware and software system.

Remember these are days before we had the minimum viable product (MVP) concept to experiment, create, learn, and experiment again.

Without scrum to create such a sophisticated infrastructure that constituted numerous hardware and software elements was a real challenge.

Here are three significant setbacks we used to have without any scrum masters and anyone who possesses a scrum master certification in our teams.
Had To Plan The Entire Project Before Understanding The Project? This Might Surprise You!

Without scrum, our teams had built and delivered entirely wrong software and hardware products that did not fulfill demands from our client.

We had times in our professional lives when some third party companies had imposed how we supposed to build our software products or software services.

Capability Maturity Model (CMM), ISO 9001:2008 and other derivates attempted to help our companies to ensure we build our correct software in correct ways.

How successful they used to be is not part of this book. This book was meant to focus on the scrum process and meri ts of the scrum framework rather than criticizing almost extinct procedures.

However, I have to add that these process improvement frameworks before the scrum software engineering framework recommended a phased approach. They advised a phased software engineering approach which we called the Waterfall Software Engineering Model.

With the Waterfall Model, each software project was supposed to start with requirement analysis, where we aimed to understand what our client needed and wanted.

Then we designed these requirements, we implemented them, we tested (verified) them, and we maintained them in our software production environments. Finally, we reached to end of the software engineering lifecycle.

Nonetheless, the reality didn’t play out like that!

Had To Plan The Entire Project Before Understanding The Project? This Might Surprise You!
The Waterfall Methodology vs The Scrum Framework

Had To Plan The Entire Project Before Understanding The Project? This Might Surprise You!
Phases in the Classical Waterfall Software Development Model

The adverse effects of unforeseen delays happened during a particular phase of the Waterfall Software Engineering Model were inevitable to the following software engineering phases.

Studies have shown that in over 80% of the investigated and failed software projects, the usage of the Waterfall Methodology was one of the critical factors of failure. But why?

As shown on the left side, when deploying the Waterfall Methodology, there is a strict sequential chain of the different project phases. A previous phase has to be completed before starting the next phase. Going back is, in most cases, painful, costly, frustrating to the team, and time-consuming.

The project timeline is planned at the start. A releasable product is delivered only at the end of the project timeline. If one phase is delayed, all other phases are delayed too.

To avoid this, project managers of the Waterfall Methodology usually try to anticipate all possibilities beforehand. That means that in one of the earliest phases of the project, they try to define all requirements as fine-grained and complete as possible. However, requirement definition in an initial stage of a project is often complicated, and therefore many requirements change (or should change) throughout the project.

Studies have shown that in more extensive and complex projects, about 60% of the initial requirements do change throughout the course of projects. Other requirements are implemented as define, but some of them are not really needed by the customer. So those implementations consume time and money that could have been better used to implement functionality with a higher added value for its clients.

The separation into different project phases forces project managers to estimate each phase separately. The problem is that most of these phases usually are not separate. They are working together and in parallel.

For instance, no reasonable human-being can assume that the development phase finished before the testing phase started. And yet, this is precisely and unfortunately how the Waterfall Methodology used to work.

The Waterfall Methodology for developing software can be used for implementing small and straightforward projects. But for bigger and more complex projects, this approach is highly risky, if not insane. It’s often costlier and always less efficient than Scrum software development and delivery framework.

This was the life before the Scrum framework. Sending our software back and forth between various teams, without the guidance of professionals with the Scrum skills, made our work bureaucratic, complex and unproductive.

Finally, it wasn’t only the product which suffered, but also employee morale and commitment to our organizational mission have wholly disrupted.

Overcoming A Lack Of Commitment, Change Management & Team Work! This Might Surprise You!

The most significant weakness of process improvement frameworks used before Scrum was that: They mainly focused on self-serving organizational demands of leadership.

Some of these demands are monitoring, compliance, and predictability. There was no focus on serving clients well and increasing employee morale at all.

Thus members of software management teams and various other internal and external stakeholders attempted to have a fixed deadline for software delivery projects and easily monitor the progress of software engineering phases.

They penalized their people if something was outside the planned track, and they hoped to fix emerging issues before the scheduled date of project completion.

Furthermore, independent silos realized entirely separated software engineering phases. As an example, the development team was completely independent of a software testing (verification) team. Most people who supposed to work for the same business mission didn’t even know each other by their names.

Have you got a guess about the reason for this silo-mentality in our organizations rather than focus on business missions and professional (business) maturity of employees?

The reason is simply the matrix management . Matrix management is an organizational management and employee structure, and it has been in our businesses since the 1970s. At first glance, the differentiating idea behind a matrix organization or matrix management seems to be smart.

The Leadership creates an organizational structure by bringing together employees with similar kinds of functional and technical skill-sets into the same or at best neighbor silos.

Overcoming A Lack Of Commitment, Change Management & Team Work! This Might Surprise You!
The Waterfall Project Delivery Model in a Matrix Organization

Back in times, it was quite popular to see the so called “Center of Competences” in our companies where each center of competence represented an independent and autonomous silo.

One silo for C++ developers, another silo for database administrators, and another entirely separate quality assurance silo in oversees and it goes on and on. Go and figure!

The biggest challenge with the matrix organizational structure was that: To deliver a software project without the scrum framework and scrum masters, project managers had to borrow employees from silos temporarily.

These employees did not even physically position with their project teams, but they still located in the rooms of their particular center of competences.

Up upon completion of projects, these temporary project teams dissolved and project participants moved on their next assignments to serve for other projects.

Therefore, the targeted business values of these ongoing software projects have never been the utmost priority for these independent silos.

They tend to see their work as checkboxes they ticked for one project over here and another project over there.

Leadership and matrix organizational model didn’t teach them how professionals should commit their business to improve the bottom line, including sales, revenue, and profit.

A McKinsey Quarterly article written by McKinsey & Company has also clearly illustrated this illusion of cost optimization beyond the matrix organization .

Gartner has estimated that organizations worldwide have been yearly spending 600 billion USD to recover their IT systems from non-scheduled maintenance work and defects.

Now let’s take a short moment to visualize how the change management and impediment handling of software projects played out. How t hey pl ayed out i n a proj ect configuration with the waterfall model, with the matrix organization, and without the scrum process.

Yes. You’re right.

Management and employees treated change management, impediment, and error handling as if they’re ill exceptions which shouldn’t have happened in the first place.

Therefore, changes in a software project have been the synonym of delays. They usually created a domino effect of cascading delays. Teams required someone to blame and finger point for defects and impediments.

Last, but not least, because silos did not have a mechanism in place to process, fix, and learn from their errors, they kept on repeating the same mistakes.

Furthermore, they kept on augmenting the amount of technical debt while they passively attempted to deal with their problems.

Why Should Democratic Decisions Not Be Overruled? This Might Surprise You!

Steve Jobs once said:

“It doesn’t make sense to hire smart people and tell them what to do. We hire smart people, so they can tell us what to do.”

However, this is precisely opposite of how most of the mainstream leadership used to operate to make decisions before the scrum era.

Before we had the scrum process in our organizations, autocratic decisions from leaders overruled the combined intelligence of their teams.

They invalidated the democratic decision making ability of groups who were in charge of doing the real works which spanned the entire software engineering lifecycle from the conception of software to its operations.

The remoter a decision was shifted away from work centers (teams) it impacted, the more default it was to give a correct mission-critical decision.

The judgments from leaders used to be usually impulsive, not thoroughly thought-out, mostly late and tentative, but sometimes even too early.

These autocratic decisions imposed from the top made employees feel undervalued. They entirely hindered the ability of their organizations to come up with creative and innovative solutions to handle competitive business and software-related challenges.

Furthermore, they discouraged software engineering teams from giving their inputs at the times when they’re asked to contribute decisions.

It was a brief overview of how we used to develop and deliver our software services and service products before we adopted the scrum framework in our organizations.

Now let’s have a look at how we sorted out these chaos and frustration elements with the help of the scrum process.

What Makes The Scrum Framework Succeed? This Might Surprise You!

The Scrum Framework changes the classic triangle of project management.

Organizations do no longer need to sacrifice one of the time, budget, or quality. The new triangle is now emerging between the budget, time, and functionality. And none of these project success elements have to be endangered.

What Makes The Scrum Framework Succeed? This Might Surprise You!
Triangle of Project Management

According to the Scrum framework, quality is no longer optional. To deliver what clients are paying for to flourish their businesses, the Scrum Teams strive to provide the best possible software they’re jointly able to build.

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). 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 fulfil their DoDs. Scrum Product Owner and the Scrum Team define user stories and their tasks throughout the course of the Scrum software engineering process incrementally.

This incremental development allows the team to remain adaptive and adjust their next best actions in a controlled manner without the additional costs and risks of jeopardizing large chunks of previous work.

The Scrum Team builds a potentially shippable software product increment until the end of each Sprint. The team demonstrates and discusses these increments with the Scrum Product Owner and client stakeholders to get and incorporate their feedback towards the next steps of their project.

This flexibility applies to not only software delivery but also the operational processes. So, the Scrum Framework allows the optimization of the use of resources (human, time, budget, material) and the minimization of wastes.

Studies have shown that Scrum has the following positive effects in practice:

More frequent code deployments,
Faster lead time from committing to deploying code,
Faster mean time to recover from downtime,
Lower change failure rate,
Better product quality,
Reduced or identical costs compared to pre Scrum deployment,
Improved productivity and throughput,
Improved code and operational reliability,
Enhanced organizational performance and client satisfaction,
Improved market penetration, market share, and profitability of organizations,
Improved market capitalization growth,
Improved motivation of employees.
Introducing and adopting the Scrum Framework is non-trivial. And yet, the adaptive and iterative approach of the Scrum Framework handles this initial burden, and it copes with ever-changing client and business requirements better.

Thus, the Scrum Framework is, in most cases, a better alternative to the classical software engineering methodologies.

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

Learn Scrum Framework Using Real World Case Study! This Might Surprise You!

Before Starting The First Sprint

Alex works as the Scrum Product Owner of a new software development project. One of his first tasks is to assess and find out requirements to deliver business value his client is looking for.

He needs to make sure that his client will get the correct software to achieve tangible business results. He writes down the essential use cases and discusses them with the architects, client representatives, and other stakeholders from IT and business units.

After assembling the high-level use-cases and requirements, he writes them into the Scrum Product Backlog and initiates an estimation and prioritization session with the Scrum Team. As a result of this session, all items in the Scrum Product Backlog get an initial rough estimate and priority.

During those sessions, Anna, the Scrum Master, ensures that everyone speaks the same language. So, the Scrum Product Owner, the Scrum Team Members, and their stakeholders are aligned with the anticipated goals. So they have an adequate understanding of potentially new concepts for them, such as Use Case, Backlog, Sprint, and so on. And most importantly, the Scrum software development and delivery process is correctly applied in the store.

Now Alex, the Scrum Product Owner, begins to break down the high-level requirements into the first draft of smaller-grained user stories. With this list, he then calls for the first Sprint Planning Meeting.

Sprint 1 – Day 0

During the Sprint Planning Meeting, Alex presents the Scrum Product Backlog items from the highest priority to the lowest. The Scrum Team asks and clarifies open questions. For each item, the team discusses if they have enough 25 capacity and the required know-how to develop and deliver it. The Scrum Team needs to ensure that all required human and technical resources are in place before the start of the Sprint. They need to confirm that all prerequisites and dependencies are fulfilled, which could be critical to delivering certain software features successfully.

During Sprint Planning Meeting (What-Part), the Scrum Team commit to complete the user stories 1,2,3,6,7 and 8 until the end of the Sprint. So these user stories are now moved from the Scrum Product Backlog to the Sprint Backlog. The user stories 4 and 5 cannot be accomplished in this Sprint, as some prerequisite technical infrastructure is not yet in place.

After the What-Part of the Sprint Planning Meeting, Anna, the Scrum Master, calls the Scrum Team to drill down how the team is going to implement the committed user stories (How-Part). The emerging tasks during the How-Part of the Sprint Planning Meeting are written down on the cards, and the team store them into the Sprint Backlog. Now all members of the Scrum Team are ready to select a task to begin to work on.

Sprint 1 – Day 1

In the morning, the whole team gets together for their Daily Scrum Meeting. Everyone gives a brief and concise statement about what he or she has done so far, updates the estimates of remaining work on the cards of the Sprint Backlog. Everyone tells what he or she is planning to do today, and reveals if there are any impediments which hinder them from processing any tasks.

Today one of the Scrum Team members, Melinda, informs the Scrum Team that she has a problem with the license of the integrated software development environment she is using. Anna, the Scrum Master, checks if other team members have the same problem and confirms that she’ll take care of this impediment after the meeting. After about 15 minutes of this Daily Scrum Meeting, everyone goes back to work.

After this meeting, Anna updates the Sprint Burn down Chart to visualize the progress of work during this Sprint. Then she calls the software vendor, orders the missing license, and delivers it to Melinda.

Learn Scrum Framework Using Real World Case Study! This Might Surprise You!
Introduction to Scrum A Real World Example (Case Study ) across various Scrum Phases and Sprints

Sprint 1 – Day 2

In the morning, the whole team gets together again for their Daily Scrum Meeting. In the afternoon, a member of the Scrum Team, James, has uncertainty about the expected outcome of one of the user stories. He calls Alex, Scrum Product Owner, and they discuss this user story to ensure that James properly understands it. After Alex gets informed and confident about how to proceed with this user story, he continues working on its implementation.

Sprint 1 – Day 6

The days starts again with the Daily Scrum Meeting of the team. Anna, the Scrum Master, notices this morning that the meeting tends to take more than 15 minutes. The Scrum Team members are engaging with a discussion regarding the optimization of some database queries. Anna reminds the team that the Daily Scrum Meetings are not meant to do the work, but formally aligning the team about the work and bringing them on the same page.

After the Daily Scrum Meeting, Alex (Product Owner) informs Anna (Scrum Master) that the client brought up several new requirements that may potentially impact the ongoing Sprint and the subsequent Sprints. Anna politely reminds Alex that the Scrum Team is unable to pick up these requirements during the current Sprint as the team has already committed to the scope (user stories) of this Sprint. And yet, Anna calls a Backlog Refinement Meeting for the afternoon so that Alex can inform the team about these new requirements.

During this meeting, the group supports Alex to figure out where these user stories fit the overall development plan of the software, their initial task break-down, estimates, and priorities.

Sprint 1 – Day 10

Finally, that’s the last day of this first Sprint. Anna, the Scrum Master, invites the Scrum Team for the Sprint Review Meeting. The team has prepared a non-production server with the latest version of the shippable software increment they created.

Alex, the Scrum Product Owner, and Mr. Rich, one of the client stakeholders, sit in front of an instance of a graphical user interface of this software. They validate if the implementation meets the expectations and if the team documented details regarding the current level of application adequately.

At the end of the Sprint Review Meeting, Alex concludes:

The team delivered user stories 1,2,6 and 7 as committed and expected.
The team couldn’t finish the user story 3 on time, and they didn’t demonstrate this user story at all. So, the remaining tasks of this user story are shifted to this next Sprint.
The user story 8 did not fulfill some of its Definition of Done (DoD) criteria. This user story is moved to the next Sprint, so the team can define and complete the associated tasks to satisfy the DoD of this user story later.
Alex, the Scrum Product Owner, and Mr. Rich, the client stakeholder, shortly debrief the Scrum Team about the upcoming changes and challenges about the software requirements and the direction of the overall strategy about this software should be going. Mr. Rich thanks the Scrum Team for their efforts and commitment and leaves the room.

After the completion of the Sprint Planning Meeting, the Scrum Team sits together for the Sprint Retrospective Meeting. During this meeting, they discuss what went well during the Sprint and what could be improved, so that the likelihood of failed commitments like it happened with user stories 3 and 8 will reduce in the next Sprints. One of the hurdles identified from the Sprint Retrospective Meeting is that the team do not know enough about the overall system architecture. Anna, the Scrum Master, takes over the task of bringing a system architect on board to coach and guide the team at the beginning of the next Sprint.

Sprint 2 – Day 1

Alex, the Scrum Product Owner, keeps on adding new requirements to the Scrum Product Backlog based on his recent client meetings. Moreover, he improves the way he articulated DoD of user story 8, so the Scrum Team can better envision the expected outcome from this user story.

Alex then invites the team for the Sprint Planning Meeting for Sprint 2. The Scrum Team discuss and commit to user stories with the guidance of Anna, the Scrum Master, and subsequently, the second Sprint begins.

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

What Are The Five Key Values Of The Scrum Framework? This Might Surprise You!

We have already mentioned that the scrum framework is not only a software engineering process. It also has a robust set of underlying principles.

In fact, most of the professional business domains can apply and utilize these principles.

It’s not enough to get a scrum certification to be hugely successful with the scrum. You should possess a firm grasp for scrum values to succeed with the Scrum framework

So that you’re going to deliver a great job and fantastic software that your customers and employers love. Let me now tell you more about those principles of the scrum process.

Scrum Value #1. Courage

There are times when doing the correct thing to serve the best values and benefits for our clients are not the easiest. In such moments, scrum master, scrum product owner, and the scrum team members should remember their duty and obligation.

That’s to build the best possible products and services in their particular business and information technology domain. To be better than mediocre, a scrum team should sooner or later face difficult decisions that won’t make everyone happy in their particular ecosystem of stakeholders.

To deal with this, all members of the scrum team should remember what they learned during their scrum certification training.

They should remember to be courageous, and they should master to decide and act courageously.

Scrum Value #2. Focus

With the scrum framework, when you hear the value focus, you should be thinking about two things:

Identification of correct work: What tasks are necessary to deliver the goals of my sprint? What are essential to developing the best software products and services for my clients so that they will be pleased with my work?
Prioritization: What tasks should I be working on next?
Each moment in time, there is one critical question that the entire scrum team, including scrum master and product owner, must be answering.

This question is: “What are the most important things we should be doing at the moment to fulfil reasons of why an employer hired us in the first place?”

Scrum framework has several built-in events (rituals) to ensure the reasonable prioritization of user stories and tasks. According to the scrum process, the prioritization of user stories and their associated tasks should have a continuous priority.

So we make sure that the scrum team works on the right things in the correct order.

Some of the built-in scrum ceremonies (scrum events) to prioritize our work and adjust our focus are:

Scrum Grooming (Backlog Refinement) Meeting: Grooming Meeting solely focuses on prioritization for Product Backlog to prepare it before the upcoming Sprint Planning Meeting.
Sprint Planning Meeting: These meetings help us see the dependencies and correct order of work to deliver our user stories.
Daily Scrum Meeting: Daily Scrum (Daily Stand-Up) Meeting supports us to set the tone of an upcoming workday. We must direct our focus on where it’s most required.
Sprint Review Meeting: Sprint review meeting indirectly shows us where the emphasis of the 21 scrum team must be channeling to have more successful reviews in the future.
Sprint Retrospective Meeting: These meetings support the scrum team to prioritize what aspects of their engineering process must be first improved.
Here in this section, I covered scrum rituals only from a focus point of view. You can find a more detailed explanation about the scrum ceremonies later in this material.

Having read all these, it must be evident for you now how essential prioritization and focus for the scrum framework are.

Scrum Value #3. Commitment

Without the commitment of scrum master, scrum product owner, and the scrum team, there is no possibility to deliver outstanding results with software.

In the world of the scrum software development process, most people translate the commitment value as the agreement and confinement of goals of given sprint deliverables.

Although this entirely makes sense, that understanding is not flawless. Whenever you hear the word “commitment” within the context of scrum values; what you should remember is the word: “obsession”.

To be successful in software engineering and, in life and business, you should become obsessed with your goals. So in the context of the scrum process, you should become obsessed with creating marvelous software for your clients to solve their problems.

Why are commitment and the associated obsession with scrum goals so important? Because without the obsession with the team’s mi ssi on to bui l d and del i ver astoni shi ng software, each time the scrum team encounters a non-trivial impediment, your work will slow down and stall.

Then the scrum master and the scrum team will start creating explanations to justify and legitimize for scrum product owner why they’re unable to deliver sprint goals. Excuses should have no more room in your team if your goal is to become a better than an average scrum team.

Only with an enormously high level of dedication, it’s relatively more comfortable and fulfilling to solve the problems of our clients and help and build value for them with software.

Scrum Value #4. Respect

Regardless of their age, gender, race, belief, experience, competence, opinions, and work performance, every member of a scrum team must respect and count on each other.

This respect is not only confined within the boundary of the scrum team. Moreover, every internal or external IT and business stakeholder who interacts with the scrum team is utterly respected and welcomed by a scrum team.

Experienced team members must pay attention in order not to invalidate the willingness of the contribution from less experienced team members.

It’s particularly crucial to properly receive and answer opposite opinions that the majority of the group do not agree with.

Scrum Value #5. Openness

The scrum value “openness” is often one of the primary differentiators between an average and high-performer scrum team. It would help if you resembled the openness capability of a scrum team to the vast ability of a collection of open minded individuals.

They’re creative, innovative, intellectual, honest, direct, and humble. In the scrum software engineering and delivery process, there is no inappropriate opinion, decision, and action.

The only condition is that they must be transparent, and they should aim to contribute to the joint mission of the scrum team.

It doesn’t mean that every decision and action must necessarily accelerate the outputs of the scrum team, and they should result in substantial success stories.

Thanks to openness and courage values, the scrum software development group is not afraid of making mistakes.They see their errors and less than optimal outcomes as vital chances to meaningfully improve their overall productivity and quality of work.

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

What Is Self Organization In Scrum Framework? This Might Surprise You!

The scrum team organizes itself. Scrum team members decide in consensus about tasks they need to execute to deliver the goals of a sprint. A self-organized team doesn’t require a manager or a team leader.

Self-organization in the scrum framework is very disciplined.

Sprint Backlog, Sprint Burn down Chart, and Daily Scrum Meetings which you are going to learn more about them later in this material build the foundation of self-organization.

Organizing the work by themselves requires for the most teams a learning phase. Competent scrum masters who own scrum master certifications support their scrum teams to excel with self-organization quickly.

Self-organization also includes the ability to work together despite different opinions and possible conflicts among various scrum team members. Self-organization requires compliance and trust in joint decision-making processes.

Those decision-making process in the scrum framework includes, but not limited to, planning, estimating, implementing, reporting, and reviewing the work the scrum team is jointly responsible.

What Is Self Organization In Scrum Framework? This Might Surprise You!

Yes? Then you need to bring up a team that can self-organize its own work!

What Is Inspect And Adapt In Scrum Framework? This Might Surprise You!

Scrum Inspect and Adapt is a straightforward concept to comprehend, but the hardest to properly implement and master.

Companies have finally confirmed that none of their project managers can fully foresee the big picture of complex systems. They were unable to do reliable end-to-end planning. It was evident for them that they needed to try something different.

Together with lean manufacturing (also known as lean movement), companies needed to develop a process to empower them strategically. They needed a standard operating procedure to help them learn and fix their courses of action while they’re running their projects and even operations.

That was the birth of Toyota Improvement Kata, which we today call “Inspect and Adapt” while we talk about scrum software development and delivery framework.

According to “Scrum Inspect and Adapt”:

Step 1. Inspect: We do our best to grasp the current status of the project with our current level of know how and understanding about it.
Step 2. Adapt: We define a direction and vision about the next steps of our project and then strategize and execute our vision.
Step 3. Learn: We carefully observe, learn, and teach each other while we do so. We continuously log what works and what doesn’t work while we do our work.
Step 4. Restart: Start over from Step 1 again.
Note that those four steps described above are analog, but not limited to the following Scrum rituals (Scrum events).

Step 1. Inspect is analog to Sprint Review Meetings and Sprint Retrospective Meetings.
Step 2. Adapt is analog to Sprint Planning Meetings and Backlog Refinement Meetings.
Step 3. Learn is analog to Daily Scrum Meetings.
Step 4. Restart is analog to the closure of a sprint and the start of a new sprint.

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

What Is Agile Manifesto? This Might Surprise You!

When the IT industry talks about the Scrum framework, It’s also often we hear the term “Agile Scrum” along the same lines as “Scrum”. It led some of us in the industry to think and look for differences between the terms “Agile Scrum” and “Scrum”.

Here is good news for you. “Agile Scrum” and “Scrum” terms do both refer to the same thing. They both refer to the Scrum software engineering process. Then why do we sometimes use the word “Agile” in front “Scrum”?

It’s because the scrum framework fully embraced and embedded the Agile Manifesto (Manifesto for Agile Software Development) to its core process, principles, and underlying philosophy. That brings us to understand the agile manifesto and the values of the scrum process better before we deep-dive the technicalities of the scrum process.

Agile manifesto values:

Individuals and interactions over processes and tools,
Working software over comprehensive documentation,
Customer collaboration over contract negotiation,
Responding to change over following a plan.
While the factors on the right-hand side do still possess significant values, the agile manifesto appreciates and prioritizes the factors on the lefthand side higher.

The elements favored by the agile manifesto have been carefully time-tested and chosen to:

Serve clients and stakeholders better and create value for them with software,
Enhance the profession of software engineering regardless of your role, title, and career level.

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

What Is The Scrum Framework? This Might Surprise You!

What is Scrum? Well, without making things too complicated, the Scrum framework can be defined as the following:

Scrum is an iterative software engineering process to develop and deliver software.

Although the software is the main focus of the Scrum framework, iterative and agile Scrum process can be and is already being applied outside the software industry as well.

Most people in the IT industry believe that the term “Scrum” was coined early in the 2000s as a parallel track of emerging agile software development and delivery trends. That is a piece of incorrect information!

The term “Scrum” was first used and published by Harvard Business Review in January 1986. Hirotaka Takeuchi and Ikujiro Nonaka coined the term “Scrum” with their article: The New New Product Development Game. (Yes, two News) You should have a look at “The New New Product Development Game” to see how everything all about Scrum got started!

Scrum can be used in all kinds of software development projects. To develop and deliver complete software packages or only some modules of larger systems — both for products and services of internal and external clients.

The Scrum Framework is a lightweight process. It focuses on increasing the productivity of teams while reducing wastes and redundant activities.

Scrum defines some general guidelines with a few rules, roles, artifacts, and events. Nevertheless, all of these components are critical, serve for specific purposes, and they are essential for the successful use of the Scrum framework.

What Is The Scrum Framework? This Might Surprise You!

The main components of Scrum framework are:

Three Scrum Roles: The Scrum Product Owner, the Scrum Team, and the Scrum Master.
Five Scrum Events (Scrum Rituals) or Ceremonies: Scrum Grooming (Backlog Refinement) Meeting, Sprint Planning Meeting, Daily Scrum Meeting, Sprint Review Meeting, and Sprint Retrospective Meeting.
Product Backlog (Scrum Backlog) or Scrum Product Backlog: An artifact that is used to manage and prioritize all of the known requirements of a Scrum project.
Sprints: Cycles of work activities to develop shippable software product or service increments.
Sprint Backlog: An artifact to keep track of requirements committed by the Scrum teams for a given Sprint.
Self-organization and unconditional collaboration are critical elements of the Scrum framework. Scrum Teams do no longer require a project manager in a classical sense. With the Scrum framework, the Scrum Master and the Scrum Product Owner share the role and responsibilities of a typical project manager.

Nonetheless, a Scrum Master or a Scrum Product is never allowed to overrule the democratic decision-making capability of a Scrum Team. For instance, only the Scrum team members can jointly commit which ones of highly prioritized Backlog items they will deliver in a Sprint as a software increment.

Another central element with the Scrum framework is the continuous improvement that we enable with “inspect & adapt”. A Scrum Team continuously monitors, inspects, and assesses their artifacts and their use of Scrum framework to adapt and optimize them. These continuous efforts for optimization maximize quality, efficiency, client satisfaction, and therefore minimize wastes and overall project risks.

The Scrum framework understands that the requirements are likely to change and they are not entirely known, especially at the beginning of projects.

Every project has unknown unknowns. Sometimes a few, sometimes a lot. The Scrum framework helps us embrace that we can discover and deal with these unknown unknowns only while we are running our projects.

The Scrum Team first fine-tunes and granularizes the lower-level or low priority requirements before it implements them. During Scrum Grooming (Backlog Refinement) and Sprint Planning Meetings. Openness for change, continuous optimization, and learning from errors are now becoming integral elements of the whole software engineering lifecycle.

Another cornerstone of the Scrum framework is transparency and direct communication. The Scrum Product Owner works closely with the Scrum Team to identify and prioritize requirements. These requirements are written down as user stories and stored in the Scrum Product 15 Backlog. The Scrum Product Backlog consists of all tasks that need to be implemented to deliver a working software system successfully.

A Scrum Team is empowered to select the user stories with which they are confident to deliver within the 2-4 weeks of Sprints. Because the Scrum Team commits its own goals, the team members feel more engaged, and they know that their opinions are listened to. This inclusion of Scrum team members to the natural flow and planning of software projects increases the team morale and subsequently augments the team performance.

Scrum Masters possess another vital role in the Scrum Framework as they work as servant leaders for and with their Scrum Teams.

Scrum Masters are trained facilitators to ensure flawless operation of their Scrum Teams. Sometimes they are master negotiators to protect their Scrum Teams from interruptions and fictive priorities of their stakeholders. Other times they are master communicators to remove or prevent known or anticipated impediments before these impediments bring their teams to dead-end streets. To only call a few of the responsibilities of Scrum Masters. We will cover more about the duties of various Scrum roles later.

The Scrum Framework, in its pure form, is best suitable for highly independent, one team green field or brown field projects.

However, the practical common sense of Scrum professionals did not stop there. With the introduction of additional roles and addendums such as “Chief Scrum Product Owner” and “Scaled Scrum”, it can be used within different project configurations too, including multi-team and geographically distributed project setups. We will cover more about these as well.

For now stay tuned and keep on enjoying the lecture!

International Scrum Institute™ is an independent institute. We help organizations and professionals get certified with worldwide renowned and valid Scrum certification programs and prove their competence in the Scrum domain. We empower professionals globally to build their careers, and organizations to create and sell their outstanding products and services that their clients will love.

Your renowned Scrum certification programs have proven their worldwide recognition by being the choice of more than 594,000 Scrum professionals in 143 countries.

Before International Scrum Institute™ was established for you, there used to be pressing challenges for Scrum professionals like yourself.

You didn’t possess a reasonable alternative to get your Scrum certifications and prove your competence in the Scrum domain. Scrum professionals had to pay expensive fees for the one way profit-driven Scrum certification programs of other certification entities. Moreover, they had to pay hefty prices for classroom training, recurring certification renewals, and various additional recurring subscriptions and memberships.

International Scrum Institute™ aims to remove these barriers set in front of the Scrum professionals in developed and emerging markets. We are here to save you from paying unreasonable fees for Scrum classroom training and Scrum certification programs before you certify your knowhow in Scrum.

International Scrum Institute™ provides ten major online Scrum certification programs. These programs have been designed by our consortium of renowned business and people leaders, coaches, mentors, experts, and authorities from all major industries.