SPM

SOFTWARE PROJECT MANAGEMENT

SCRUM
JDD.MUNEZERO
Scrum:
Framework: Scrum is a specific framework for Agile software development. It
provides a structured approach with defined roles, events, artifacts, and rules to
guide the development process.

Agile:
Philosophy: Agile is a broader philosophy or mindset focused on iterative and
incremental development, continuous improvement, customer collaboration, and
flexibility in responding to change.
Agile project management provides great solutions for certain types of work.
There isn't a planning or project management methodology that is the best one.
There is no one size fits all.
• Instead, we should think about them as different tools in the project manager's toolbox.
• When a need for a project arises, the organization will need to choose the most appropriate tool for the specific type of
work at hand.
• If you need to drive nails into a piece of wood, you would probably go for a hammer and not a screwdriver.
• Agile methodologies are considered particularly useful for complex work,and note that complex should not be
confused with something just difficult or complicated.
• Instead, it intends work that involves many interrelated factors and many unknowns at the same time.
• Complex problems can be analyzed from many different perspectives.
• Complex problems can be analyzed from many different perspectives.
• Hence, the possible solutions would also be many.
• Understanding which is the best one in advance and predicting how the various factors will interact is very difficult.
• Trying to apply a formula or algorithm to such cases will not solve the problem.
• Hence, creating a plan with a high probability of success is hardly achievable.
• This is why adopting the so-called predictive planning where you try to predict and forecast everything in
advance as done in waterfall, is not going to be beneficial.
• Instead, the suggested way for complex environments would be to perform adaptive planning
• where the plan is gradually developed and updated as the project progresses and uncertainties unveil.
In real life, a typical example is the product development initiatives where a product goes all the way from just
an idea or concept through to its realization and finally, to its adoption.
We need to remember that all products have certain characteristics: functionalities, capabilities, features.
In other words, what can we do with this product? How useful is it? What are its limitations? How well does it serve its
purpose? Hence, from a project management perspective, the requirements will be mostly linked to these functionalities,
capabilities and features. Keep that in mind as these concepts will be frequently mentioned in the following lessons.
• In these initiatives, there usually are a few considerations which make them qualify as complex work.
• The users of the future product.
• Often, they do not have experience with the product before it's created.
• That makes it hard for them to imagine how they'll be working with it and hence define their exact needs, requirements
and expectations.
• The creators of the product.
• These can be IT developers, engineers, technicians, artists, designers, or other experts who will be building or
manufacturing the product.
• Working without fixed requirements creates difficulties also on their side.
• The technology itself, it always includes uncertainties which sometimes may create a bad surprise for a project manager.

Now is the right moment for us to introduce one of the most widely adopted methodologies
designed for such environments and types of projects, Scrum.
Scrum is a popular framework used in software project management, particularly in Agile software development. It's
designed to help teams work together more effectively to develop complex products.
Scrum emerged during the 1990s as a framework for delivering complex work such as software development.
The methodology, however, has evolved also outside the software domain and has been successfully adopted in
other fields - the broader product development, R&D, problem solving or also in cases when an organization does
not have a lot of experience with the given work that is to be performed such as a pilot project, creating a
prototype or performing an experiment.
Scrum practitioners openly acknowledge that the product requirements, or in other words, what the future users
want from the product may vary.
• Scrum practitioners openly acknowledge that the product requirements, or in other words, what the future users
want from the product may vary.
• As the project progresses, the users or customers may change their perception, their desires and needs.
• Not only that but also other factors that may influence the work in an unpredictable way, such as technology like we
already mentioned, different coding languages, programs, systems, possible integrations and other factors make the
software world difficult to comprehend when observed passively from the outside.
• Hence, the project manager, sponsor, et cetera should not try to block this dynamic, but instead, follow it to capture
all the changes that are beneficial to the end goal.
• Being a product that is useful to its future user and this is where Scrum would come into play.
• The name Scrum actually comes from the game rugby and indicates the moment when the teams regroup after a game
interruption.
• The parallel with the sport also highlights that experts with different backgrounds cooperate as a team towards a
common objective as it cannot be achieved if all these professionals work separately.
Hence, this cross-functional team works as one and passing the ball to one another through a number of short phases
progresses towards scoring or achieving the goal.
 Scrum project structure.
let's gain an understanding of how the project lifecycle and project structure looks in Scrum.
• The lifecycle starts in the traditional way with an initiation phase where a project is defined and analyzed.
• Then, planning occurs, but on a more high level.
• The team usually performs workshops to understand the scope, to find high level timeline and budget, and build the
project team.
• Here, we need to have a good understanding of what kind of a need the product of the project should satisfy.
• What future users should be able to do with it and what technologies will be used.
• The question of how, exactly to achieve this, however, will be answered gradually from when the work starts.
• And here we have the distinctive part of Scrum, the way the work is executed.
 In Scrum, a sprint is a time-boxed iteration during which a development team works to produce a potentially
releasable increment of a product. Sprints are typically short, lasting between 1 to 4 weeks, with 2 weeks being the
most common duration. During a sprint, the team focuses on completing a set of predefined work items from the
product backlog.

• As we saw in the introduction , the cross-functional team is running towards the desired destination in short phases.
• These short phases indicate what we know from Agile as iterations.
• In Scrum, these phases are called sprints. The sprints represent a fundamental part of a Scrum project lifecycle.
• Each one is usually between two and four weeks long and has to deliver a given part of the product.
• Collectively, all sprints in a project need to deliver the entire product with all desired capabilities.
• As per the Agile practices, each sprint ends up with a demo session where the team presents the progress to the
customer, allowing them to understand how the particular part of the product functions.
• Here, the customer may request reworks if the requirements are not covered or if needed, request changes to the
requirements for the upcoming sprints.
• As you already know, this characteristic gives the needed flexibility to make modifications or even change the
direction of the whole project if it's beneficial towards achieving the goal.
Note however, changes during a sprint are not allowed, only in between them.
• Before moving to the next sprint, the project team holds a brief session to discuss the lessons learned from a previous
sprint. It's called a retrospective or retro.
• In this way, the team can immediately catch issues in their way of working and implement the improvements as of the very
next sprint, instead of collecting lessons learned only at the end of the project and applying them to the next project.
• We explained that a certain amount of planning takes place before the sprints start.
• The knowledge that the team has at the end of it has to cover what the scope or product will be.
• Before the sprints can start, the scope has to be allocated to the different sprints.
• This exercise is usually performed between the initial planning and the first sprint and is called sprint zero.
• A plan is created, indicating how many tasks per sprint the team is targeting to achieve, which parts of the product to
create first, which ones second, et cetera.
• Also, this deep dive has to determine how many sprints in total are needed to create the whole product, and hence fulfill
the scope.
• By understanding the total number of sprints and knowing their standard duration, this exercise also gives the project
overall target completion date.
• If, for example, we need five sprints, each three weeks long, the target completion date will be in 15 weeks time.
• After the work of the last sprint is completed, a closure phase should always be present at the end.
• Here, the customer will have to accept the product as a whole, confirming that it will satisfy the need,
hence achieve the project goal.
As per the established best practices, this is a mandatory step for any project manager before they can officially finalize a project.
 User Stories ( scope )

• We will now learn how a scope is structured in a SCRUM project.

• After all, we need to know what all this running is about, In the last lesson, we saw how the product scope was
divided in pieces and how they were allocated to the different sprints.
• In a SCRUM project, the documentation which contains the scope and requirements is called product backlog.
• The backlog represents the full list of requirements including all functionalities, features, and attributes that the final
product should have.
• The backlog represents the full list of requirements including all functionalities, features, and attributes that the final
product should have.
• It will be the key document to refer to whenever the product scope is discussed.
let's see in more detail how the product backlog is formed, studying a few important elements.
• In product development projects, the scope has to include not only the physical or tangible part of the product itself,
but also the part about how people will use the product once it's ready.
• Topics such as how useful the product is, how easy it is to work with, how fast it is, what the user experience is like.
• These need to be captured and added to the requirements.
• If the scope of a project is a website for ordering pizza, for example, aspects such as how easy it is for somebody to
navigate through the site and be able to quickly compare options, make a choice, and order the desired pizza, would
be very important.
• The focus cannot be only on creating the technical side of a website and missing such details
• In order to be more comprehensive when capturing and documenting all kinds of requirements, SCRUM projects use
the so-called user stories.
• A user story is a one sentence description of a specific desire, a capability of the system, a product feature, usually
written by a person or a group of people who will be the future users.
• Let's see some examples so we better understand.
• If we use our pizza website, possible user stories could be:
• Remember how each user story starts with, "As a user,
• I want to be able to..."? This way of describing a requirement helps people open their minds and explain in a very
practical way
• what will be important to them, exactly as a story.
• This way of describing a requirement helps people open their minds and explain in a very practical way what will be
important to them, exactly as a story.
• Furthermore, once this description gets to the technical team, it will be easier to put themselves in the shoes of the user
and understand what is in their heads. Less room for misunderstandings.
• Note that our first example actually provides more details.
• It follows the format, "As a user, I want to be able to...“ "In order to..."
• This gives the technical team the opportunity to advise on alternative solutions to the same problem, and potentially
find a better way of reaching the user's goal. So, next time when you start gathering user stories
User stories seem really useful indeed.
• The process of gathering, discussing, and documenting them begins during the initial planning activities.
• It can happen in different ways.
• For example, the future users, or if the group is too big, e.g., consumers in a given market, representatives of these
users are invited to workshop sessions where they brainstorm together and generate the user stories.

• Another possible scenario is having user stories provided by the so-called product owner, or the person in charge of the
product scope in a SCRUM project.
• We will get back to this role a bit later.
• There may also be other ways of collecting stories and requirements, but it is important to give the chance to all
relevant project stakeholders to contribute to this process with their knowledge and experience.

• A fun fact, user stories are typically associated with sticky notes, because when collected in a workshop, this is usually
the way to write them down for the first time. Hence, you can often see a picture or a logo of a sticky note associated
with the user stories.

• Of course, even if collected in this way, user stories should always then be documented in an electronic format.
• See how beneficial and also interesting it is to describe requirements via user stories?
 EPICs
• In scrum, in EPIC is considered a big piece of work which refers to an important set of product requirements.
• It can be broken down into smaller pieces of work.
• In other words, one EPIC basically includes a number of user stories.
• Using again our tasty example, an EPIC would be the broader order payment functionality.
• This can also be described similarly to a user story.
• Let's say as a user, I want to be able to pay online in order not to exchange cash with the delivery person.
• It may sound like a user story, but it is a bigger piece of work.
• Under this EPIC, we would have all user stories that are related to this functionality, such as pay via debit and credit card, pay
via PayPal, pay cash, pay via Bitcoin.
• So the relationship between EPICs and user stories is hierarchical. User stories are grouped and assigned under the
respective EPIC, or in the other way around, if you have defined the EPICs first, they get broken down into user stories. But
what is the borderline between an EPIC and a user story?
• They might sound similar to people that are not knowledgeable of the technical work needed to create either of them.
• If you get into doubt whether a given feature should be defined as an EPIC or as a user story, remember the following
guideline.
• If the feature can be created within a single sprint, it should be considered as a user story.
• An EPIC, on the other hand, is considered a bigger functionality which cannot be completed within only one sprint and will
require a few sprints of time and effort.
• Okay, so story by story and EPIC by EPIC, the project team defines and describes the entire product scope and requirements
and what functionalities and features it should have.
• Great, we learned the fundamentals of the scope in a scrum project.
The relationship between EPICs and user stories is hierarchical
• User stories are grouped and assigned under the respective EPIC, or in the other way around, if you have defined the
EPICs first, they get broken down into user stories.
• But what is the borderline between an EPIC and a user story? They might sound similar to people that are not
knowledgeable of the technical work needed to create either of them.
• If you get into doubt whether a given feature should be defined as an EPIC or as a user story, remember
the following guideline.
• If the feature can be created within a single sprint, it should be considered as a user story.
• An EPIC, on the other hand, is considered a bigger functionality which cannot be completed within only one sprint and
will require a few sprints of time and effort.
• Story by story and EPIC by EPIC, the project team defines and describes the entire product scope and
requirements and what functionalities and features it should have.
• Great, we learned the fundamentals of the scope in a scrum project.
 Product Backlog.

• After the product requirements have been gathered in user stories and epics, it's time to structure the product backlog.
Similar to the way we created an activity list from the work breakdown structure in the case of a traditional waterfall
project, the user stories from the different epics are also listed together to form the product backlog.
• Remember how the user stories were described?
• As a user, I want to be able to... et cetera, et cetera.
• This description served its purpose during the requirements gathering phase, but now we need to translate it so it
sounds more task-orientated.
 Product backlog items

• By transforming the initial user stories in that way, we create something like a to-do list for the development team.
• The user stories become formalized as part of the backlog.
• Note, the term product backlog items or PBIs, may also be used by certain organizations to indicate the list of work
items in the backlog.
• As we already know from the previous Scrum lessons, the pieces of work or user stories are distributed through the
project sprints.
• You remembered well, this happens during sprint zero.
• Let's see if you remember another advantage of the Agile methodologies.
• The product is developed step-by-step, generating completed parts of the product throughout the project and not as a
whole, only at the very end.
• When a bigger functionality or a group of functionalities is completed, let's say an epic or a group of epics, the Scrum team
completes a product release.
• That basically means that users can now start using this part of the product scope for business purposes, even if the
project continues working on the remaining parts of this product.
• In this way, with a Scrum methodology, the organization could start benefiting from the newly developed product way
before the whole development project is completed.
• This is a great strategic advantage as it decreases the so-called time to market or the period between the moment
somebody has an idea and the moment of having an actual product introduced to the market.
• Of course, as the project progresses and new functionalities are released, the product becomes more and more complete.
• This is very much the case of software development projects where the most important functionalities are
programmed first so people can start using and testing them in a real life environment.
• Then additional features can be added or released once ready, thus upgrading the product further.
• it's a good moment to introduce another very important concept.
MVP
 Quick example.
• Say, in our pizza delivery case, we have three main epics.
• One, the basic website with the menu list where you can choose a pizza.
• Two, the online payment functionality where you can pay for the selected pizza and finalize the order.
• Three, make your own pizza functionality with which the customer can select the exact ingredients and order a
custom pizza.
• Which functionalities and features do you think the MVP must include in this case?
• In other words, what are the functionalities without which the pizza restaurant cannot start offering deliveries
and introduce its new service to the market?
• It would not make sense to start offering deliveries without either being able to select a pizza and be able to pay
for it to complete the order.
• The third epic seems like a really nice feature too.
• However, it is definitely not critical for the website to start working.
• So most probably these will be one and two.
• Meaning MVP during release two.
• The definition of the MVP is a key moment as it sets a clear target for the project, defining the features without which
the product cannot be used in any way.
• With an MVP in place, the organization can start benefiting from the project work and in the meantime, collect
feedback from early adopters for the following releases, which are still to be done.
 Key Roles in scram Project

• We learned what a Scrum project looks like.

• We saw how the project is executed in sprints how the scope gets described through user stories and epics
resulting in the product backlog.
• We also know that each sprint will have to deliver a specific item of this backlog, how the product is delivered step-
by-step through releases and what the minimum viable product or MVP stands for.
• But what is the thing that is always behind all these concepts and activities?
• People.
• Remember, projects are done by people, for people.
• The agile philosophy explicitly highlights this point promoting close collaboration between those two groups, the
people that do the project and the people that will benefit from the project.
 1. The product owner.

• This is a critically important role for a successful Scrum project that will be the person owning the product backlog,
including all key aspects and decisions related to it.
• In the beginning, they are responsible for defining and validating the requirements including user stories and epics.
• Furthermore, the product owner defines what the priorities are within the product backlog list.
• Which user stories should the team build first, which ones second, and which ones can be left for later.
• Then as the sprints start they are the ones reviewing all outputs during the demo sessions and validating whether
the requirements are met.
• And finally, they are the ones approving the finalized product at the end of the project.
• Usually, the product owner represents the organization for which the product of the project is created.
• In other words, this is the project client as we know it.
• Hence, the person needs to be knowledgeable and experienced enough in the field.
• Often this is a manager or senior manager from the business field or business function, head of sales, head of
marketing, head of IT, et cetera.
• They need to combine the ability to look strategically at the project, but also have a good expertise in the field.
• Since the product owner is such an important role, they need to be working closely with the team throughout the entire
project.
• As mentioned, they are the ones to review the output on each demo session and either validate that it reflects the
requirements, or if not, they need to provide constructive feedback to the development team why the output is not
meeting the desired standards.
• Note another critical point .
• In-between the sprints, the product owner is the one who can approve a change to the priorities of the backlog items
and that is a point we now know well from Agile, the requirements can change.
• So here there is this key person who can say, if a task or a user story with a bigger value has to be prioritized bringing
more important work earlier, of course in accordance with the project team.
 2. The development team.
• Logically, these are the people physically creating the product.
• In software projects, these will be the friendly IT engineers programming the software.
• In a research project for a new medicine, these will be the scientists performing the chemical development and experiments.
• In a project for creating a new space shuttle, these will be engineers or physicians, and so on and so forth.
• These professionals are experts in the given field.
• As such, during the planning and brainstorming sessions, they need to advise the project team on the technical side of the
requirements.
• How much time is needed to achieve all of them? Are all of them achievable at all? Are there any other solutions to the same
problem, which may be better? The development team plays an important role in the backlog definition process too.
• After the user stories are generated by the various stakeholders and the product owner has defined the
priorities, the development team will need to assess the related work from a technical perspective.
• They must determine how much effort each user story requires in order to be built.
• Even if we see them as a list, the different user stories require different amounts of time and effort.
• In Scrum, the amount of effort is measured in story points.
• A user story with two story points would take twice as much effort compared to a user story with one story point.
• Note, we are talking about effort, not simply time.
• If, for example, one IT engineer can deliver one story point per week for user story A, which is to the left of the
screen, it will take a total of two weeks since it consists of two story points.
• However, if a second engineer who is as productive as the first one joins, they will be able to deliver user story A in
only one week,
• If, for example, one IT engineer can deliver one story point per week for user story A, which is to the left of
the screen, it will take a total of two weeks since it consists of two story points.
However, if a second engineer who is as productive as the first one joins, they will be able to deliver user story A in only
one week, very good.
• The development team has the responsibility to assign story points to each user story in the backlog list.
• This gives important information to the product owner and the other project stakeholders as the amount of effort may
change the way they prioritize the work.
• If two user stories are considered with a similar priority at the beginning, but when the story points are assigned, it turns
out they require a different amount of effort, it is likely that the product owner prefers to push the one requiring more
story points for later in the project.
• This would leave more room for the development team to complete more stories early on.
• with the story points assigned to each user story, there is one more thing to be determined, and that is the capacity of
our development team.
• In other words, how many story points can they deliver in a certain sprint?
• In Scrum, they call this velocity.
• Let's say our team has three developers, and they can deliver about one story point per week.
• This makes about three story points per week as a team.
• And if we assume the sprints in our project are two weeks long, this would mean the velocity is three times one times
two, which equals six story points per sprint.
• This data is also fundamental as it enables the project team to realistically plan the sprints and say what is expected to
be delivered and when.
 Quick exercise.

• If we use the example on the screen and we know the development team velocity is six story points per sprint, try
to calculate how many sprints are needed to deliver the user stories on the screen, which correspond to the
minimum viable product or MVP of this project.
 What's your answer?

• If you said four, you're correct.

• We have a total of nine user stories and the associated effort is 22 story points.
• We divide the total story points by the velocity and we get 22 divided by six, which equals 3.7.
• This means three sprints will not be sufficient, but during the fourth sprint, it will be completed, great job.
• Just before we finish this lesson, there is one more thing worth mentioning.
• In our example, we showed how user stories are built one at a time.
• This means completing the first story and only then starting the second one.
• In real life projects, there is also the option of working on a few user stories in parallel, especially if there is a
bigger development team, so keep that in mind.
 3. Scrum master.
• Last, but definitely not least, we have the scrum master.
• Their responsibility extends beyond the separate functions as they are accountable for the success of the scrum team.
• This includes supporting the product owner and development team in performing their duties successfully, validating that
their work is in line with the scrum goals, and coordinating the activities between them.
• Also, they act as a main point for communication between the scrum team and the rest of the project stakeholders or
broader organization.
The scrum master oversees all critical activities,
• Their responsibility extends beyond the separate functions as they are accountable for the success of the scrum team.
• This includes supporting the product owner and development team in performing their duties successfully, validating that
their work is in line with the scrum goals, and coordinating the activities between them.
• Also, they act as a main point for communication between the scrum team and the rest of the project stakeholders or
broader organization.
• The scrum master oversees all critical activities, such as comprehensive backlog planning efficient management of the
backlog, along with any changes, coordination between the team members, and removal of any roadblocks or issues in
front of the team.
• Also, the scrum master incorporates the role of a coach, a mentor, supporting everyone involved in building their
knowledge of the scrum practices and values, and then ensuring the team correctly adopts them from the beginning until
the end of the project.
• They perform training and coaching sessions and also use the retrospectives, or retros, to identify possible improvements
to the way scrum principles are followed.
• That is something quite unique about this role.
• In a typical scrum project, the scrum master is also responsible for leading a number of scrum-specific sessions and meetings.
• Firstly, at the start of each sprint, a sprint planning session is held, during which the goals of the given sprint are set.
• The specific tasks to be worked on are discussed and agreed together with the product owner and the development team.
• As the sprints start each morning, the scrum master hosts a meeting called daily standups, or DSUs, with the team.
• In this meeting, everyone who attends needs to answer these three questions.
 The next session takes place at the end of each sprint and is called sprint
review.

• In this meeting, the team presents the completed work and performs a demo to the product owner and any other
relevant stakeholders.
• As you already know, here, the product owner has the responsibility to validate the output or provide feedback.
• Finally, the team performs a retrospective, or retrocession.
• The discussion here needs to cover two fundamental topics, what went well during the last sprint, and what did
not go well, and not as per the plan.
• Any improvement points are directly brought to the next sprint planning session.
• These sessions are also known as ceremonies.
• These scrum ceremonies are really important for the successful management of the scrum team and fall under the
scrum master responsibilities.
PROJECT MANAGER SCRUM MASTER
 Congratulation!
Scrum is completed