Software Development

and
Professional Practice
Lecture 3: Process Life Cycle Models
By
Dr. Rasha Mahmoud Kamel
Agile Development Methodologies
This is a sample text, Insert your desired text here this is a sample text.

■ As opposed to the heavyweight plan-driven models, the new agile process model is
lightweight. It requires less documentation and fewer process controls.

■ It is targeted at small to medium-sized software projects (say up to about 500K lines of code)
and smaller teams of developers.

■ It allows these teams to quickly adjust to changing requirements and customer demands.
■ It is proposed to release completed software much more quickly than plan-driven models.
■ Agile development works from the proposition that the goal of any software development
project is working code. And because the focus is on working software, then the
development team should spend most of their time writing code, not writing documents.
This gives these processes the name lightweight.
WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 2
Agile Development Methodologies
This is a sample text, Insert your desired text here this is a sample text.

■ Lightweight methodologies have several characteristics. They tend to emphasize writing

tests before code, frequent product releases, significant customer involvement in
development, common code ownership, and refactoring (rewriting code to make it simpler
and easier to maintain).

■ Lightweight methodologies also suffer from several myths. The two most pernicious are
probably that lightweight processes are only good for very small projects, and that you don’t
have to have any process discipline in a lightweight project.

■ The truth is that lightweight methodologies have been successfully used in many small and
medium-sized projects. They also require process discipline, especially in the beginning of a
project when initial requirements and an iteration cycle are created.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 3

eXtreme Programming (XP)
This is a sample text, Insert your desired text here this is a sample text.

■ XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop
software. XP relies on the following four fundamental ideas:

(1) Heavy customer involvement: XP requires that a customer representative be part of the
development team and be on site at all times. The customer representative works with the
team to create the contents of each iteration of the product and creates all the acceptance
tests for each interim release.

(2) Continuous unit testing (also known as test-driven development [TDD]): XP calls for
developers to write the unit tests for any new features before any of the code is written. It
gives a developer a clear metric for success. When all the unit tests pass, you have
finished implementing the feature.
WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 4
eXtreme Programming (XP)
This is a sample text, Insert your desired text here this is a sample text.

(3) Pair programming:

● XP requires that pairs of developers (two programmers) write all code – a driver and a
navigator – who share a single computer.

● The driver is actually writing the code while the navigator watches, catching typos,
making suggestions, thinking about design and testing, and so on.

● The pair switches places periodically (every 30 minutes or so, or when one of them
thinks he has a better way of implementing a piece of code).

● Pair programming works on the “two heads are better than one” theory.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 5

eXtreme Programming (XP)
This is a sample text, Insert your desired text here this is a sample text.

(3) Pair programming:

● While a pair of programmers is not quite as productive as two individual

programmers when it comes to number of lines of code written per unit of time, their
code usually contains fewer defects, and they have a set of unit tests to show that it
works. This makes them more productive overall.

● Pair programming also provides the team an opportunity to re-factor existing code –
to re-design it to make it as simple as possible while still meeting the customer’s
requirements.

● Pair programming is not exclusive to XP, but XP was the first discipline to use it
exclusively.
WhirlWind P O W E R P O I N T T E M P L A T E | Email : [email protected] | Web : www.example.com 6
eXtreme Programming (XP)
This is a sample text, Insert your desired text here this is a sample text.

(4) Short iteration cycles and frequent releases:

● XP typically uses release cycles in the range of just a few months and each release is
composed of several iterations, each on the order of 4–6 weeks.

● The combination of frequent releases and an on-site customer representative allows

the XP team to get immediate feedback on new features and to uncover design and
requirements issues early.

● XP also requires constant integration and building of the product. Whenever a

programming pair finishes a feature and it passes all their unit tests, they
immediately integrate and build the entire product.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 7

eXtreme Programming (XP)
This is a sample text, Insert your desired text here this is a sample text.

(4) Short iteration cycles and frequent releases:

● They then use all the unit tests as a regression test suite to make sure the new feature
hasn’t broken anything already checked in.

● If it does break something, they fix it immediately.

● So in an XP project, integrations and builds can happen several times a day.

● This process gives the team a good feel for where they are in the release cycle every
day and gives the customer a completed build on which to run the acceptance tests.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 8

eXtreme Programming (XP)
This is a sample text, Insert your desired text here this is a sample text.

■ Risk is the most basic problem in software.

■ Risk manifests in many ways: schedule slips, project cancelation, increased defect rates,
misunderstanding of the business problem, false feature rich (adding features the customer
really doesn’t want or need), and staff turnover.

■ Managing risk is a very difficult and time-consuming management problem.

■ XP seeks to minimize risk by controlling the four variables of software development.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 9

XP – The Four Variables
This is a sample text, Insert your desired text here this is a sample text.

■ The four variables of software development projects are as follows:

(1) Cost: it is probably the most constrained and as a developer you have very limited
control over cost.

(2) Time: it is your delivery schedule and is unfortunately usually imposed on you from the
outside. For example, most consumer products (be they hardware or software) will
have a delivery date in late summer or early fall in order to hit the holiday buying
season. If you are late, the only way to fix your problem is to drop features or lessen
quality; neither of which is pretty.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 10

XP – The Four Variables
This is a sample text, Insert your desired text here this is a sample text.

(3) Quality: it is the number and severity of defects you are willing to release with. You can
make short-term gains in delivery schedules by sacrificing quality. It will take more
time to fix the next release and your credibility is pretty well shot.

(4) Features (scope): it is what the product actually does. This is what developers should
always focus on. It is the most important of the variables from the customer’s
perspective and it is also the one you as a developer have the most control over. If the
developers don’t have control over the feature set for each release, then they are likely
to blow the schedule.

■ XP recognizes that to minimize risk, developers need to control as many of the variables as
possible, but especially they need to control the scope of the project.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 11

XP – The Four Values
This is a sample text, Insert your desired text here this is a sample text.

■ In XP, there are the following four core values that enable it to work:
(1) Communication:

● Communication really means spreading the collective knowledge of the group around
to all the members.

● Keeping the XP team small facilitates communication.

● Pair programming and collective ownership of the code also facilitate communication
by spreading the knowledge of the entire code base around the entire team.

● XP developers are encouraged to fix bugs they find and to redesign features to make
them simpler; this spreads knowledge of the code widely among the team.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 12

XP – The Four Values
This is a sample text, Insert your desired text here this is a sample text.

(2) Simplicity:

● XP focuses on developing the simplest piece of software that solves today’s task.

● XP developers bet that “...it is better to do a simple thing today and pay a little more
tomorrow to change it if it needs it, than to do a more complicated thing today that
may never be used anyway”.

● All developers on an XP team are allowed and encouraged to redesign code to make it
simpler at any time (refactoring).

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 13

XP – The Four Values
This is a sample text, Insert your desired text here this is a sample text.

(3) Feedback:

● XP programmers are required to write tests before they write the code, so that they
always have immediate feedback about their code and its impact on the system.

● Also, the customer is writing functional (acceptance) tests so those are available to
measure how well the system is adhering to the “stories” used to develop it.

(4) Courage:

● XP developers must have courage.

● They must be willing to make changes at any time when the design no longer fits.

● They need to be prepared to throw code away if it doesn’t work.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 14
XP – The 15 Principles
This is a sample text, Insert your desired text here this is a sample text.

■ From the four values, XP derives some basic principles. The list looks like the following:
(1) Rapid feedback: Get feedback, understand it, and put it back into the system as quickly
as possible.

(2) Assume simplicity: Focus on today’s task and solve it in the simplest way possible.
Simplify the code whenever you are making changes (Refactoring) to keep it as simple
as possible and reduce defects.

(3) Incremental change: Integrate your new code into the system every day or whenever
you finish a task. This allows you to find interface and interaction errors quickly and
gives the customer a new baseline to examine at least once a day.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 15

XP – The 15 Principles
This is a sample text, Insert your desired text here this is a sample text.

(4) Embracing change: It’s gonna happen, so be prepared for it. The whole basis of agile
methodologies like XP is that change is a constant in software development and the
more your discipline accommodates change, the better your development process will
be.

(5) Quality work: Strive for defect-free code. Pair programming and test-driven
development (focuses your code on satisfying requirements) help lead to fewer defects
in your code.

(6) Teach learning: Teach how to learn to do testing, refactoring, and coding better rather
than set down a set of rules that say, “you must test this way.”

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 16

XP – The 15 Principles
This is a sample text, Insert your desired text here this is a sample text.

(7) Small initial investment: If you start a project with fewer resources and a tight budget,
it will focus your thinking on lean design and code. This reinforces simplicity.

(8) Play to win: If you don’t worry about schedules, or requirements churn, your days will
be more relaxed, you’ll be able to focus on the problems at hand (and not on the next
deadline) and your code will be cleaner, you will be more relaxed and more productive.
Just relax and win.

(9) Work with people’s instincts, not against them: People like winning. People like
interacting with others. People like being part of a team. People like seeing their code
work. People like being trusted. Don’t do things that go against this. Give them the
environment and support they need, and trust them to get the job done.
WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 17
XP – The 15 Principles
This is a sample text, Insert your desired text here this is a sample text.

(10) Concrete experiments: Every abstract decision (requirements or design) should be

tested. You produce something called a spike which is a quick and dirty proof-of-
concept piece of code that implements at least the outline of your decision so you can
see if you are actually right or not. If you are wrong, you have not wasted lots of time
figuring that out.

(11) Open, honest communication: You have to be able to criticize constructively and be
able to deliver bad news as well as good. The idea is two-fold: First, you are all trying
to improve the code so criticism is a good thing. Second, common code ownership
means that everyone is entitled to make changes without fear of hurting someone else’s
feelings.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 18

XP – The 15 Principles
This is a sample text, Insert your desired text here this is a sample text.

(12) Accepted responsibility: The team as whole is responsible for the product.
Responsibility is accepted by the entire team and tasks are not assigned. Common code
ownership leads to common project ownership. XP teams typically do not have
managers that assign work; they have a coach to help with the process and a project
manager to take care of the administrative tasks. The development team members
themselves select tasks and make sure they get done.

(13) Local adaptation: XP is adapted to local needs and requirements. Change XP to fit
your local circumstances and project. This is an application of accepted responsibility.
The team owns the project, so the team also owns the process and they reach
consensus on adaptations.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 19

XP – The 15 Principles
This is a sample text, Insert your desired text here this is a sample text.

(14) Travel light: The team and process artifacts you maintain should be few, simple, and
valuable. Keep only those models that will provide long-term value and dispose things
(code, design) that you no longer need.

(15) Honest measurement: Measure the progress of the project (e.g., working software,
customer satisfaction, team performance and productivity, etc). Measurements are
necessary to steer the project and gauge its progress. These measurements should be
transparent, honest and comprehensible to all project participants.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 20

XP – The Four Basic Activities
This is a sample text, Insert your desired text here this is a sample text.

■ XP describes four activities that are the bedrock (foundation) of the discipline:
(1) Coding:

● The code is where the knowledge of the system resides so it is your main activity.

● The fundamental difference between plan-driven models and agile models is this
emphasis on the code.

● In agile models, the code is the sole deliverable and so the emphasis is placed
completely there.

● In addition, by structuring the code properly and keeping comments up to date, the
code becomes documentation for the project.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 21

XP – The Four Basic Activities
This is a sample text, Insert your desired text here this is a sample text.

■ XP describes four activities that are the bedrock (foundation) of the discipline:
(2) Testing:

● XP depends heavily on writing unit tests before writing the code that they test.

● The tests tell you when you are done coding.

● XP depends on using an automated testing framework to run all the unit tests
whenever changes are integrated.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 22

XP – The Four Basic Activities
This is a sample text, Insert your desired text here this is a sample text.

(3) Listening: To your partner and to the customer.

● In any given software development project there are two types of knowledge: domain
knowledge and technical knowledge.

● The customer has knowledge of the business application being written and what it is
supposed to do. This is the domain knowledge of the project.

● The developers have knowledge about the target platform, the programming
language(s), and the implementation issues. This is the technical knowledge.

● The customer doesn’t know the technical side and the developers don’t have the
domain knowledge, so listening is a key activity in developing the product.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 23

XP – The Four Basic Activities
This is a sample text, Insert your desired text here this is a sample text.

(4) Designing:

● Designing is creating a structure that organizes the logic in the system.

● Design while you code.

● Good design organizes the logic so that a change in one part of the system doesn’t
always require a change in another part of the system.

● Good design ensures that every piece of logic in the system has one and only one
home.

● Good design allows the extension of the system with changes in only one place.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 24

XP – The 12 Practices
This is a sample text, Insert your desired text here this is a sample text.

■ The rules that every XP team follows during their project may vary depending on the team
and the project, but in order to call yourselves an XP team, you need to do some form of
these things:

(1) Small releases:

● Put a simple system into production quickly, and then release new versions on a very
short cycle.

● Each release has to make sense from a business perspective, so release size will vary.

● It is far better to plan releases in durations of a month or two rather than six or twelve.
The longer a release is, the harder it is to estimate.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 25

XP – The 12 Practices
This is a sample text, Insert your desired text here this is a sample text.

(2) Planning game:

● Develop the scope of the next release by combining business priorities and technical
estimates. The customer and the development team need to decide on the stories that
will be included in the next release, the priority of each story, and when the release
needs to be done. The developers are responsible for breaking the stories up into a set
of tasks and for estimating the duration of each task. The sum of the durations tells
the team what they really think they can get done before the release delivery date. If
necessary, stories are moved out of a release if the numbers don’t add up. Notice that
estimation is the responsibility of the developers and not the customer or the
manager. In XP only the developers do estimation.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 26

XP – The 12 Practices
This is a sample text, Insert your desired text here this is a sample text.

(3) Metaphor:

● “A simple shared story of how the whole system works.”

● The metaphor needs to be a coherent explanation of the system that is decomposable

into smaller bits – stories. Stories should always be expressed in the vocabulary of the
metaphor and the language of the metaphor should be common to both the customer
and the developers.

● The metaphor is a naming concept for classes and methods that should make it easy
for a team member to guess the functionality of a particular class/method, from its
name only.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 27

XP – The 12 Practices
This is a sample text, Insert your desired text here this is a sample text.

(4) Simple design:

● Keep the design as simple as you can each day. Re-design often to keep it simple.

● A simple design should (1) pass all the unit tests, (2) have no duplicated code, (3)
express what each story means in the code, and (4) have the fewest number of classes
and methods that make sense to implement the stories so far.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 28

XP – The 12 Practices
This is a sample text, Insert your desired text here this is a sample text.

(5) Testing:

● Programmers constantly write unit tests.

● Customers constantly write functional tests.

● Tests must all pass before integration.

● In short, any program feature without an automated test simply doesn’t exist.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 29

XP – The 12 Practices
This is a sample text, Insert your desired text here this is a sample text.

(6) Refactoring:

● Restructure the system to make it simpler without changing its behavior via
removing redundancy, eliminating unnecessary layers of code, or adding flexibility.

● The key to refactoring is to identify areas of code that can be made simpler and to do
it.

● Refactoring is closely related to collective ownership and simple design.

● Collective ownership gives you permission to change the code and simple design
imposes on you the responsibility to make the change when you see it needs to be
made.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 30

XP – The 12 Practices
This is a sample text, Insert your desired text here this is a sample text.

(7) Pair programming:

● All production code must be written by two programmers at one machine.

● Pair programming is a dynamic process. You may change partners as often as you
change tasks to implement.

● This has the effect of reinforcing collective ownership by spreading the knowledge of
the entire system around the entire team.

● It avoids the “beer truck problem”, where the person who knows everything gets hit
by a beer truck and thus sets the project schedule back months.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 31

XP – The 12 Practices
This is a sample text, Insert your desired text here this is a sample text.

(8) Collective ownership:

● The team owns everything, implying that anyone can change anything at any time.

● Programmers need to buy into the idea that anyone can change their code and that
collective ownership extends from code to the entire project; it’s a team project, not an
individual one.

(9) Continuous integration:

● Integrate and build every time a task is finished.

● This helps to isolate problems in the code base; if you are integrating a single task
change, then the most likely place to look for a problem is right there.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 32

XP – The 12 Practices
This is a sample text, Insert your desired text here this is a sample text.

(10) 40-hour week:

● Work a regular 40-hour week. The XP philosophy is that the people are less
productive if they are working more than 40 hours a week than if they are working 40
hours.

● Constantly being under deadline pressure and never getting a break also means you
get tired and then make more mistakes, which somebody then needs to fix.

● But working 40-hours a week leaves you with time for a life, time to relax and
recharge, and time to focus on your work during the workday, making you more
productive, not less.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 33

XP – The 12 Practices
This is a sample text, Insert your desired text here this is a sample text.

(11) On-site customer:

● A customer is part of the team, is on-site, writes and executes functional tests, and
helps clarify requirements.

● The customer’s ability to give immediate feedback to changes in the system also
increases team confidence that they are building the right system every day.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 34

XP – The 12 Practices
This is a sample text, Insert your desired text here this is a sample text.

(12) Coding standards:

● Because of collective code ownership the team must have coding standards and
everyone must adhere to them.

● Without a sensible set of coding guidelines, it would take much, much longer to do
refactoring and it would decrease the desire of developers to change code.

● Your coding standards should make your code easier to read and maintain.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 35

Scrum
This is a sample text, Insert your desired text here this is a sample text.

■ Scrum is a variation on the iterative development approach and incorporates many of the
features of XP.

■ Scrum is a project management methodology. It doesn’t define many of the detailed

development practices (like pair programming or test-driven development) that XP does.
Despite this, Scrum teams typically use many of the XP practices. Common code ownership,
pair programming, small releases, simple design, test-driven development, continuous
integration, and coding standards are all common practices in Scrum projects.

■ Scrum uses teams of no more than 10 developers. It emphasizes the efficiency of small teams
and collective ownership.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 36

Scrum
This is a sample text, Insert your desired text here this is a sample text.

■ Scrum is characterized by the sprint, an iteration of between one and four weeks.
■ Sprints are time-boxed in that they are of a fixed duration and the output of a sprint is what
work the team can accomplish during the sprint.

■ The delivery date for the sprint does not move out. This means that sometimes a sprint can
finish early, and sometimes a sprint will finish with less functionality than was proposed. A
sprint always delivers a usable product.

■ Scrum requirements are encapsulated in two backlogs: the product backlog and sprint
backlog.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 37

Scrum
This is a sample text, Insert your desired text here this is a sample text.

■ Product backlog is the prioritized list of all the requirements for the project; it is created by
the product owner and scrum team. The development team breaks the high-priority user
stories into tasks and estimates them.

■ Sprint backlog is the prioritized list of requirements (user stories) for the current sprint.
■ Once the sprint starts, only the development team can add tasks to the sprint backlog –
these are usually bugs found during testing. No outside entity can add items to the sprint
backlog, only to the product backlog.

■ Scrum projects have a daily scrum meeting, which is a stand-up meeting of 15–30 minutes
duration where the entire team discusses sprint progress.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 38

Scrum
This is a sample text, Insert your desired text here this is a sample text.

■ The daily Scrum meeting allows the team to share information and track sprint progress.
Thus, any slip in the schedule or any problems in implementation are immediately obvious
and can be addressed by the team at once.

■ Scrum projects are facilitated by a ScrumMaster whose job is to manage the backlogs, run
the daily Scrum meetings, and to protect the team from outside influences during the sprint.
The ScrumMaster is usually not a developer.

■ The ScrumMaster ensures that everyone makes progress, records the decisions made at the
meeting and tracks action items, and keeps the Scrum meetings short and focused.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 39

Scrum
This is a sample text, Insert your desired text here this is a sample text.

■ At the Scrum meeting, each team member answers the following three questions in turn:
(1) What tasks have you finished since the last Scrum meeting?

(2) Is anything getting in the way of your finishing your tasks?

(3) What tasks are you planning to do between now and the next Scrum meeting?

■ This meeting type has several effects. ● It allows the entire team to visualize progress
towards the sprint and project completion everyday. ● It reinforces team spirit by sharing
progress – everyone can feel good about tasks completed. ● And finally, it verbalizes
problems – which can then be solved by the entire team.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 40

Scrum
This is a sample text, Insert your desired text here this is a sample text.

■ The development team itself is self-organizing; the members of the Scrum team decide
among themselves who will work on what user stories and tasks, assume collective
ownership of the project, and decide on the development process they will use during the
sprint.

■ Before the first sprint starts, Scrum has an initial planning phase that creates the list of the
initial requirements, decides on an architecture for implementing the requirements, divides
the user stories into prioritized groups for the sprints, and breaks the first set of user
stories into tasks to be estimated and assigned. They stop when their estimates occupy all
the time allowed for the sprint. Tasks in a sprint should not be longer than one day of effort.
If a task is estimated to take more than one day of effort, it is divided into two or more tasks.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 41

Scrum
This is a sample text, Insert your desired text here this is a sample text.

■ At the end of the sprint two things happen:

● First, the current version of the product is released to the product owner, who may
perform acceptance testing on it.

● Second, the team will hold a sprint retrospective meeting to congratulate themselves on
jobs well done, ponder the just completed sprint, and look for areas in which they can
improve performance for the next sprint.

■ After each sprint, another planning meeting is held where the ScrumMaster and the team
re-prioritize the product backlog and create a backlog for the next sprint. This planning
meeting is also where the organization can decide whether the project is finished, or whether
to finish the project at all.
WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 42
Scrum
This is a sample text, Insert your desired text here this is a sample text.

■ With most Scrum teams, estimates of tasks become better as the project progresses because
the team now has data on how they have done estimating on previous sprints. This effect in
Scrum is called “acceleration”; the productivity of the team can actually increase during the
project and get better at estimating tasks.

■ After the last scheduled sprint, a final sprint is done to bring closure to the project. This
sprint implements no new functionality, but prepares the final deliverable for product
release. It fixes any existing bugs, finishes documentation, and generally productizes the
code. Any requirements left in the product backlog are transferred to the next release.

WhirlWind POW ERPOINT TEMPLATE | Email : [email protected] | Web : www.example.com 43