A Statistical Analysis of The Effects of Scrum and Kanban On Software Development Pro-Jects
A Statistical Analysis of The Effects of Scrum and Kanban On Software Development Pro-Jects
A Statistical Analysis of The Effects of Scrum and Kanban On Software Development Pro-Jects
art ic l e i nf o a b s t r a c t
Article history: Traditionally, software development processes have relied on the use of the Waterfall and Vee
Received 10 April 2015 models. Later, Agile methodologies were used to handle the challenges of managing complex projects
Received in revised form during the development phase. Agile methodologies are a group of incremental and iterative methods
16 September 2015
that are more effective, and have been used in project management. Kanban and Scrum are two powerful
Accepted 9 December 2015
Available online 17 December 2015
Agile project management approaches in software development. The objective of Scrum and Kanban is
achieved by optimizing the development process by identifying the tasks, managing time more effec-
Keywords: tively, and setting-up teams. A review of the literature reveals that there is a lack of statistical evidence to
Project management factors for software conclude which methodology is more effective in dealing with the traditional project management
development
factors of budget handling, risk control, quality of the project, available resources, having clear project
Agile movement
scope, and schedule handling. This research statistically compares the effectiveness of the Scrum and
Scrum methodology
Kanban methodology Kanban methods in terms of their effects on the project management factors for software development
projects. Numerical analysis is performed based on survey responses from those with experience in the
Scrum and Kanban methods. Results suggest that both Scrum and Kanban lead to the development of
successful projects, and that the Kanban method can be better than the Scrum method in terms of
managing project schedule.
& 2015 Elsevier Ltd. All rights reserved.
1. Introduction incremental and iterative in nature [1] and others were linear and
sequential, known as Waterfall Model [2]. The Waterfall model
While project management methodologies have been used for assumes that the team has nearly perfect information about the
a very long time and date back to the Egyptian era, organizations project requirements, the solutions, and ultimately the goal.
adopted the methods only half a century ago. During the mid Hence, changes in requirements were not encouraged, and became
1900s, the defense, navy, and space research industries were the an expensive affair. Nevertheless, the sequence of steps in the
rst to adopt effective project management methodologies to Waterfall model is rarely followed in the actual system design [3],
achieve organizational goals. By the early 1990s, with the boom in and it had become evident that the approach lacked effectiveness
hardware and software engineering industries, project manage- in addressing the needs of customers, managing rapidly changing
ment methodologies found many takers and have proved effective scope, delivery time, and cost of the project [4]. The Vee Process
in helping organizations achieve tremendous results in its pro- model is yet another system process model that starts with a user
ducts. Adopting one of the project management methodologies need and ends with a completed system [3]. In this model, testing
and verication are performed at each stage of the system de-
made organizations more efcient in terms of planning, setting
velopment, starting with the low-level components and ending
timelines and budgets, and improving quality of the products that
with the higher-level components until the entire system has been
were produced.
veried. In the mid-1990s, other software development methods
By the late 1950s, there have been many trial-and-error
evolved due to problems of these so-called heavyweight software
methods in managing software development projects. The early
methodologies, which are complex and require detailed doc-
methods were used to nd better ways of gathering and dening
umentation and expensive design [5].
project requirements, analyzing problems, and conducting sys-
In 2001, the Agile movement was introduced in response to the
tematic implementations of problems. Some of the methods were failures of the Waterfall software development methodology [6].
One of the models based on the Agile movement, known as Scrum,
n
Corresponding author. is based on principles of lean manufacturing [6]. A different
E-mail address: [email protected] (H. Lei). methodology based on the Agile movement is called Kanban,
http://dx.doi.org/10.1016/j.rcim.2015.12.001
0736-5845/& 2015 Elsevier Ltd. All rights reserved.
60 H. Lei et al. / Robotics and Computer-Integrated Manufacturing 43 (2017) 5967
which was inspired by the Toyota Production System [7] and by discussed and the Manifesto for Agile Software Development had
Lean manufacturing [8]. Recently, the Kanban and Scrum meth- been published to dene the framework and goals of these
odologies are two powerful methods adopted by organizations for methods [13].
software development. Although there has been a debate for years
about which of these methods are preferred, there has not been 2.2. Early history of Scrum
sufcient evidence based on statistical analysis for selecting a
preferred method. The work of Sjoberg et al. in 2012 attempted to Scrum is a project management methodology for Agile soft-
quantify the effects of Kanban versus Scrum in a case study with ware development that uses iteration and incrementation. It has
one company, but the authors suggested that their study should be been designed to manage rapidly-changing project requirements
replicated in other environments [9]. by improving communication between project developers, project
The focus of this research is to provide statistical evidence to owners, and other team members. In 1986, Hirotaka Takeuchi and
determine if there is a signicant difference between the Scrum Ikujiro Nonaka named Scrum the new product development
and Kanban methods in terms of their effects on different project standard in auto and consumer product companies [14]. Scrum has
management factors. The project management factors examined been dened, formalized, and published as the rst Agile metho-
in this work are based on the 6-point star model associated with dology for software development [15]. In 1993, Jeff Sutherland,
the Project Management Body of Knowledge [10]. The factors in- John Scumniotales, and Jeff McKenna, at Easel Company, had used
clude project scope, budget, schedule, risk, quality, and resources. Scrum for software development projects for the rst time [16]. In
In this work, the data is rst collected via a web-based survey. 2002, Schwaber and Beedle wrote the book Agile with Scrum to
Each survey question relates to one of the six project management describe Scrum methodology [17]. Although Scrum had become a
factors listed above. Next, the correlation between these factors common methodology since then, a study of Agile software de-
and the success of a project is veried by a Pearson correlation velopment shows that only 3% of the existing scientic evidence
analysis. Finally, Kanban and Scrum methodologies are compared on Agile software development focuses on Scrum [18], which this
to each other in terms of their effect on the six project manage- paper aims to address. The following sections describe Scrum
ment factors. Core results of this work have been previously methodology, including its implementation process and practices.
published and presented at the FAIM 2014 conference in San An-
tonio, Texas [11]. However, this paper describes the history and 2.3. Scrum theory
backgrounds of the methodologies in greater detail, presents re-
sults in greater detail, and provides additional analysis of the Scrum, based on empirical process control theory, is an itera-
results. tive and incremental project management methodology to control
This paper is structured as follows: Section 2 presents the risk and optimize the predictability of a project. Transparency,
history of the Agile movement, and provides background on Scrum inspection, and adaptation, which are dened below, are three
and Kanban theory. Section 3 describes the approach and techni- important factors in the Scrum process [19].
ques used in this work, and Section 4 provides a statistical analysis Transparency: The process must be visible to everyone who is
and discussion of the results. Section 5 gives a conclusion, and involved in the project.
suggests future work. Inspection: Scrum users must inspect Scrum artifacts frequently
to detect problems in early stages.
Adaptation: If an inspector determines that some aspects of the
2. Agile software development methodologies project are unacceptable and outside of the project scope, the
process can be adjusted to avoid further problems.
In this section, the evolution of Agile software development, It should be noted that it is crucial to apply these factors during
the creation of Scrum and Kanban methodologies, and their ap- different project development phases. Details pertaining to these
plications, are explained. Figures are also included to illustrate factors are presented in the following sections.
their usage for project development.
2.4. Content of Scrum
2.1. History of Agile software development
Scrum consists of Scrum teams, events, artifacts and rules. The
Prior to the emerging of Agile software development, there rules are essential to bind teams, events and artifacts together
had been many trial-and-error-based methods in software devel- during the project. They also provide an agreeable structure for
opment by the late 1950s. These methods were employed to nd resolving conicts within a project. The following sections explain
better ways of dening the project requirements, analyzing the Scrum team, events and artifacts in detail.
problem, and implementing it in a systematic manner. Some of
these were incremental and iterative in nature [1] and others were 2.4.1. Scrum team
linear and sequential, known as the Waterfall Model [2]. These The Scrum team consists of a Product Owner, a Scrum Master,
approaches generally lacked the effectiveness in addressing the and Development Team Members. Teams are self-organized and
needs of customers, managing rapidly changing project scope, cross-functional. Therefore, they have control of the project and
delivery time and cost [4]. In the mid-1990s, other software de- know how to accomplish the goals without relying on directions
velopment methods evolved due to the problems of these hea- from people outside the team [19]. The team delivers products
vyweight software methodologies, which are complex methods iteratively and incrementally, maximizing the feedback they re-
with expensive design [5]. ceive. Below are descriptions of the different Scrum team roles:
As a response to the heavyweight software methodologies, The Product owner is responsible for managing the Product
lightweight methodologies, including iterative and incremental Backlog, the list of requirements of the product, and maximizing
methods, had been developed and implemented. Examples of the value of the project. His roles also include explaining the
lightweight (Agile) methodologies are Scrum, Extreme Program- Product Backlog items and goals of the project to the Development
ming, Dynamic Systems Development Method (DSDM), Feature- Team, ensuring that the team understands these goals and per-
Driven Development (FDD) and Adaptive Software Development forms at a high level.
(ASD) [12]. In 2001, these lightweight methodologies had been The Scrum Master manages the Product Backlog and instructs
H. Lei et al. / Robotics and Computer-Integrated Manufacturing 43 (2017) 5967 61
the Development Team on creating clear Product Backlog items. 2.4.3. Scrum artifacts
The Scrum Master also communicates with the team to ensure The Scrum artifacts consist of the Product Backlog, the Sprint
that the team understands the long-term plans of the project. In Backlog, and the denition of what a Done product is after each
addition, he works with other Scrum Masters to increase the ef- Increment, which is the sum of the Product Backlog items com-
fectiveness of Scrum in the organization. pleted through the Sprints.
The Development Team is responsible for implementing and The Product Backlog contains the list of requirements, functions,
delivering the releasable product at the end of each Sprint, enhancements, and corrections needed in the product. It shows
which is a period of time (referred to as a time-box) to create a the functionality of the product from technical and business per-
usable increment of the product. The team controls the im- spectives. The Product Owner is responsible for the creation of the
plementation of the end-product. Development Team members list, and explaining the project perspective to the team. The pro-
manage their own work and are self-organized, and are not duct backlog is dynamic, as it evolves whenever progress in the
grouped into sub-teams. The size of the team is an important is- project is made.
sue; a small team may suffer from problems in the lack of skill, The Sprint Backlog is the list of items in the Product Backlog
while a large team may suffer from development complexity. It that are selected for the specic Sprint. The Development Team
has been found that the ideal size of a Development Team is seven claries the functionalities of the product that will be im-
members [19]. plemented in the next Sprint, and the work that is needed [19].
During the Sprint, if the Development Team realizes that there is
2.4.2. Scrum Events more work required, the team adds the work to the Sprint Backlog.
Scrum uses time-boxed events with project development and The remaining work in the Sprint Backlog can be tracked by the
project planning phases. Events in Scrum are designed to inspect team in order to manage the Sprint's progress.
artifacts and to adapt new methods for solving the projects pro- Fig. 2 shows an example of a project task board based on the
blems. The goals of these events are to enable transparency, Scrum process. This team uses post-it notes to keep track of the list
adaptation, and inspection in the development process [19]. Fig. 1 of tasks during a Scrum Sprint.
shows the components of each Scrum Event.
The Sprint is the heart of the Scrum process. It is a time-box to
2.5. Kanban theory
create a useable, nished product. Each Sprint can be considered
as a one-month project with a plan of what needs to be built, and
In the following sections, Kanban theory is presented to com-
how it needs to be built. The development goals of each Sprint,
plete the background knowledge that this work is based on.
along with the Development Team, should not be changed during
Kanban is another project management methodology for software
the course of the Sprint. However, the Product Owner and the
development that emphasizes just-in-time delivery. The main
Development Team may redene project scope as needed. The
focus of Kanban is to accurately state what work needs to be done,
Product Owner can also cancel Sprints if any change occurs in the
and when it needs to be done. It does so by prioritizing tasks, and
company direction, market needs, or technology.
dening workow as well as lead-time to delivery [20]. The Kan-
The Scrum team plans the goals of each Sprint, along with the
ban process explicitly presents the most important tasks that need
products implementation process, in the Sprint Planning Meeting.
the most attention in order to reduce the risk of their incomple-
The overall goal of each sprint is to create a usable and potentially
tion, and also to increase exibility amongst other tasks in the
releasable product, known as the Done product. The Scrum team
project.
members should discuss and have a common understanding of
what constitutes a Done product. The Sprint Planning Meeting
duration is usually eight hours, which occurs once a month prior
to each Sprint [19]. In addition to this meeting, there is 15-min
daily Scrum meeting where team members update one another on
their progress, their future goals for the next meeting, and dif-
culties they have experienced each day.
At the end of each Sprint, a Sprint review meeting is held to
discuss what each team member did during the product-devel-
opment iteration. This meeting can be a product demonstration to
the Product Owner, or occasionally to both the Product Owner and
the customers. After the Sprint Review Meeting and prior to the
next Sprint, a Sprint Retrospective meet is held to inspect how the
last Sprint went in terms of communication, human resources,
process, and tools, and to identify potential improvements for
future Sprints. This meeting usually takes several hours [19].
Fig. 2. Scrum task board example. Figure produced by Logan Ingalls (Task
board) [CC BY 2.0 (http://creativecommons.org/licenses/by/2.0)], via Wikimedia
Fig. 1. Components of a Scrum Event. Figure obtained from: Wikimedia.org. Commons.
62 H. Lei et al. / Robotics and Computer-Integrated Manufacturing 43 (2017) 5967
3. Research methodology
Table 1
Project management factors, survey questions and question numbers.
factor focuses on on-time project completion. The Scope factor Likert scale response Score
pertains to the mission and goals of the project and its require-
ments. The Budget factor focuses on meeting the budget require- Strongly disagree 1
ments and on achieving targeted return-on-investment. The Risk Disagree 2
Neutral 3
factor relates to how well project risks are managed. The Re-
Agree 4
sources factor pertains to human and material resources available Strongly agree 5
during the project, and the Quality factor relates to the overall
success of the project. This work aims to statistically compare the
effectiveness of Scrum and Kanban in terms of the six factors.
Table 3
Number of respondents using Scrum and Kanban.
3.1. Data collection
Methodology Number of respondents
A web-based survey (using http://www.surveymonkey.com) is
used to collect numerical responses to questions pertaining to Scrum 21
Kanban 14
each of the project management factors in the six-pointed star
model for both Scrum- and Kanban-based projects. The survey
was conducted over the period of a month (April 2012May 2012),
and responses were collected from employees who are involved in
Table 4
software development projects at companies using Scrum or Business sectors of survey respondents.
Kanban.
Table 1 shows the survey questions that relate to each of the Business sector Number of respondents
factors of the six-pointed star model. For each survey question,
Information technology 6
participants gave one of ve responses according to the Likert
Consultancy 4
scale: Strongly Disagree, Disagree, Neutral, Agree, and Strongly Education 3
Agree. Each Likert scale response is associated with a numerical E-commerce 2
score, shown in Table 2, and the scores are used to generate nu- Bank and nance 2
merical survey response data. Warranty 2
Web services 1
Data collected through the survey are divided into two subsets Tourism 1
one for data related to Scrum projects, and the other for data
related to Kanban projects. A total of 35 people responded. Among
them, 60% (21 respondents) used the Scrum methodology in their Respondents were also asked regarding the number of people
software development projects, 40% (14 respondents) used Kan- working on software projects. 45.7% of the respondents stated that
ban (see Table 3). there are 10 to 20 people working on software projects, and 42.9%
Table 4 shows the business sectors of the survey respondents, stated that there are less than 10 people.
while Table 5 shows the company sizes of the respondents. We Table 6 summarizes the survey responses for users of Scrum,
also determined that eight of the 35 respondents are project and Table 7 summarizes responses for users of Kanban. The
managers, seven are software engineers, and three are assistant average scores are also shown for the responses to each question,
project managers. 32.4% of the respondents stated that they computed by rst multiplying the number of responses falling into
worked less than 2 years, 32.4% stated that they worked from 5 to each Likert scale category (i.e. Strongly Agree, etc.) by the score (1
10 years, and 26.5% stated that they worked from 2 to 5 years. 5) associated with that category. The products for the ve Likert
64 H. Lei et al. / Robotics and Computer-Integrated Manufacturing 43 (2017) 5967
Table 5 client satisfaction are met, and whether the project is successful
Company size of survey respondents. overall. We performed a sanity check to ensure that the quality
factor is positively correlated with the other ve project manage-
Size of company Percentage of respondents (%)
ment factors for our data. A positive correlation between each of the
Less than 50 25.7 other factors with the quality factor suggests that there is merit in
50100 37.1 examining how Scrum and Kanban affects each of the individual
100500 28.6
factors, which could affect the overall success of the project.
More than 500 8.6
We computed the average score of the 2 or 3 questions per-
taining to each factor for each participant. For example, if a re-
categories are summed, and divided by the number of responses to spondent answered Strongly Agree (score of 5) for Question 1.1,
the question, to compute the average score for the question. Agree (score of 4) for Question 1.2, and Neutral (score of 3) for
Tables 6 and 7 show that there are noticeable differences be- Question 1.3, then the average score for the respondent for the
tween the average scores for some of the questions for users of Schedule factor (with questions 1.1, 1.2, and 1.3) is a 4.0. Table 8
Scrum compared to users of Kanban. For example, respondents shows the average scores of each factor for all 35 respondents.
who used Scrum had an average score of 3.76 for question 1.1 Pearson's correlation value is computed between the average
(Project teams are aware of project status) while respondents scores of all respondents for the quality factor to the average
who used Kanban had an average score of 4.36 for the same scores for the other ve project management factors. A correlation
question. This suggests that Kanban users are more aware of value of 1 indicates perfect correlation, while a value of 0 indicates
project status. The following sections further analyze and discuss no correlation. Table 9 shows the correlation values. Note that all
the results. signicance-level values are less than 0.05, indicating that the
correlation is signicant at the 95% condence level.
Correlation results show that the quality factor, which is an
4. Results and discussion indicator for project success, is positively correlated with each of
the other ve factors of the six-star model. The correlation values
This section provides statistical analysis based on the numerical are signicant, and range from 0.60 to 0.85. This suggests that
results from the survey responses, in terms of how the project man- examining how Scrum and Kanban affects each of the factors of
agement factors relate to one another, and how Kanban and Scrum the six-star model can provide insight on how the methodologies
affects each of the factors. A discussion of the results is also provided. affect the overall success of the project.
4.1. Correlation between project success and project management 4.2. Statistical comparison of Kanban and Scrum based on Survey
factors Results
The quality factor of the six-point star model is related to the Lastly, we compared the Scrum versus Kanban methodologies
overall success of the project, since the survey questions for the in terms of how they affect each of the individual project man-
quality factor examine whether project quality requirements and agement factors. Table 10 shows the mean and standard deviation
Table 6
Summary of survey responses for Scrum users.
Factor Question (number) Strongly Disagree Neutral Agree Strongly agree Avg. Response count
disagree score
Schedule Project teams are aware of project status (1.1) 4.8% 9.5% 23.8% 28.6% 33.3% 3.76 21
(1) (2) (5) (6) (7)
Project teams can adapt changes quickly (1.2) 4.8% 14.3% 14.3% 38.1% 28.6% 3.71 21
(1) (3) (3) (8) (6)
Project is delivered on time according to schedule (1.3) 9.5% 9.5% 28.6% 23.8% 28.6% 3.52 21
(2) (2) (6) (5) (6)
Scope Project usually has well dened scope (2.1) 0.0% 28.6% 14.3% 42.9% 14.3% 3.43 21
(0) (6) (3) (9) (3)
Project management methodology effective to make scope 4.8% 4.8% 28.6% 33.3% 28.6% 3.76 21
clearer (2.2) (1) (1) (6) (7) (6)
Budget Project is delivered within budget (3.1) 9.5% 0.0% 33.3% 33.3% 23.8% 3.62 21
(2) (0) (7) (7) (5)
Project provides good return on investment (3.2) 4.8% 0.0% 19.0% 33.3% 42.9% 4.10 21
(1) (0) (4) (7) (9)
Risk Project risks and opportunities are managed (4.1) 4.8% 4.8% 28.6% 47.6% 14.3% 3.62 21
(1) (1) (6) (10) (3)
Business objectives are met (4.2) 4.8% 0.0% 14.3% 47.6% 33.3% 4.05 21
(1) (0) (3) (10) (7)
Resources Human/material resources are mostly available (5.1) 4.8% 14.3% 38.1% 23.8% 19.0% 3.38 21
(1) (3) (8) (5) (4)
Teams work well together to achieve expected results (5.2) 4.8% 0.0% 0.0% 42.9% 52.4% 4.38 21
(1) (0) (0) (9) (11)
Quality Quality requirements are met (6.1) 4.8% 0.0% 14.3% 52.4% 28.6% 4.00 21
(1) (0) (3) (11) (6)
Client satisfaction is met (6.2) 4.8% 4.8% 19.0% 52.4% 19.0% 3.76 21
(1) (1) (4) (11) (4)
Project is successful overall (6.3) 4.8% 0.0% 4.8% 52.4% 38.1% 4.19 21
(1) (0) (1) (11) (8)
H. Lei et al. / Robotics and Computer-Integrated Manufacturing 43 (2017) 5967 65
Table 7
Summary of survey responses for Kanban users.
Factor Question (number) Strongly Disagree Neutral Agree Strongly agree Avg. Response count
disagree score
Schedule Project teams are aware of project status (1.1) 0.0% 0.0% 14.3% 35.7% 50.0% 4.36 14
(0) (0) (2) (5) (7)
Project teams can adapt changes quickly (1.2) 0.0% 7.1% 0.0% 64.3% 28.6% 4.14 14
(0) (1) (0) (9) (4)
Project is delivered on time according to schedule (1.3) 0.0% 14.3% 21.4% 50.0% 14.3% 3.64 14
(0) (2) (3) (7) (2)
Scope Project usually has well dened scope (2.1) 0.0% 35.7% 28.6% 21.4% 14.3% 3.14 14
(0) (5) (4) (3) (2)
Project management methodology effective to make scope 0.0% 0.0% 7.1% 64.3% 28.6% 4.21 14
clearer (2.2) (0) (0) (1) (9) (4)
Budget Project is delivered within budget (3.1) 0.0% 14.3% 7.1% 64.3% 14.3% 3.79 14
(0) (2) (1) (9) (2)
Project provides good return on investment (3.2) 0.0% 14.3% 14.3% 50.0% 21.4% 3.79 14
(0) (2) (2) (7) (3)
Risk Project risks and opportunities are managed (4.1) 7.1% 0.0% 42.9% 28.6% 21.4% 3.57 14
(1) (0) (6) (4) (3)
Business objectives are met (4.2) 0.0% 0.0% 7.1% 57.1% 35.7% 4.29 14
(0) (0) (1) (8) (5)
Resources Human/material resources are mostly available (5.1) 0.0% 14.3% 21.4% 64.3% 0.0% 3.5 14
(0) (2) (3) (9) (0)
Teams work well together to achieve expected results (5.2) 0.0% 0.0% 14.3% 35.7% 50.0% 4.36 14
(0) (0) (2) (5) (7)
Quality Quality requirements are met (6.1) 0.0% 7.1% 21.4% 42.9% 28.6% 3.93 14
(0) (1) (3) (6) (4)
Client satisfaction is met (6.2) 0.0% 14.3% 21.4% 35.7% 28.6% 3.79 14
(0) (2) (3) (5) (4)
Project is successful overall (6.3) 0.0% 0.0% 0.0% 64.3% 35.7% 4.36 14
(0) (0) (0) (9) (5)
Table 9
Table 8
Correlation between success of the project and project management factors for
Average scores of each factor for each respondent.
Scrum and Kanban.
Agil. Proj. Manag. Advis. Serv. 5 (2004) 20, Executive Update. C4media: http://www.infoq.com/minibooks/kanban-scrum-minibook, 2009
[17] M. Beedle, K. Schwaber, Get Ready for Scrum! Agile Software Development (retrieved 14.06.12).
with Scrum, 1st ed., Prentice Hall, Upper Saddle River, NJ (2002), pp. 2330. [23] L. Keogh, Scrum and Kanban both the Same, only Different. from http://liz
[18] T. Dyb, T. Dingsyr, Empirical studies of agile software development: a sys- keogh.com/2011/11/20/scrum-and-kanban-both-the-same-only-different/,
tematic review, Inf. Softw. Technol. 50 (910) (2008) 833859, http://dx.doi. 2011 (retrieved 14.06.12).
org/10.1016/j.infsof.2008.01.006. [24] M. Sahota, Scrum or kanban? yes!. From http://agilitrix.com/2010/05/scrum-
[19] K. Schwaber, J. Sutherland, The Scrum Guide, the Denitive Guide to scrum: or-kanban-yes, 2010 (retrieved 14.06.12).
The Rules of the Game. From http://www.scrum.org/Portals/0/Documents/ [25] C. Chateld, T. Johnson, Microsoft Ofce Project 2007 Step by Step. From
ScrumGuides/Scrum_Guide.pdf, 2011 (retrieved 14.06.12). http://ofce.microsoft.com/en-us/project-help/a-short-course-in-project-
[20] D. Anderson, Kanban-Successful Evolutionary Change for Your Technology management-HA010235482.aspx#BMtime, 2007 (retrieved 14.07.12).
Business, WA: David J. Anderson & Associates Inc, Seattle, 2010. [26] W.R. Duncan, Project management processes, A Guide to Project Management
[21] D. Joyce, Kanban for Software Engineering, Kanban Images. From http://lea Body of Knowledge, MD: Automated Graphic Systems, White Plains, (1996),
nandkanban.les.wordpress.com/2009/04/kanban-for-software-engineering- pp. 2739.
apr-242.pdf, 2009 (retrieved 14.06.12). [27] K. Schwaber, Agile Project Management with Scrum, Microsoft Press, Red-
[22] H. Kniberg, M. Skarin, Kanban vs Scrum: How to Make the Most of Both. From mond, WA, 2004.