8210 Exam 1 Topics

1.

What is a work breakdown structure and its purpose?

A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to
accomplish the project objectives and create the required deliverables."
There are three reasons to use a WBS in your projects. The first is that is helps more accurately and
specifically define and organize the scope of the total project. The most common way this is done is by
using a hierarchical tree structure. Each level of this structure breaks the project deliverables or objectives
down to more specific and measurable chunks. The second reason for using a WBS in your projects is to
help with assigning responsibilities, resource allocation, monitoring the project, and controlling the
project. The WBS makes the deliverables more precise and concrete so that the project team knows exactly
what has to be accomplished within each deliverable. This also allows for better estimating of cost, risk,
and time because you can work from the smaller tasks back up to the level of the entire project. Finally, it
allows you double check all the deliverables' specifics with the stakeholders and make sure there is nothing
missing or overlapping

2.

Functional and nonfunctional requirements.

Fun Req:
In software engineering (and Systems Engineering), a functional requirement defines a function of
a system and its components. A function is described as a set of inputs, the behavior, and outputs (see
also software). Functional requirements may be calculations, technical details, data manipulation and processing
and other specific functionality that define what a system is supposed to accomplish. Behavioral requirements
describing all the cases where the system uses the functional requirements are captured in use cases. Functional
requirements are supported by non-functional requirements (also known as quality requirements), which impose
constraints on the design or implementation (such as performance requirements, security, or reliability).
Generally, functional requirements are expressed in the form "system must do <requirement>", while nonfunctional requirements are "system shall be <requirement>". The plan for
implementing functional requirements is detailed in the system design. The plan for implementing nonfunctional requirements is detailed in the system architecture
Non Func Req:
n systems engineering and requirements engineering, a non-functional requirement is a requirement that
specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should
be contrasted with functional requirements that define specific behavior or functions. The plan for
implementing functional requirements is detailed in the system design. The plan for implementing nonfunctional requirements is detailed in the system architecture.
Broadly, functional requirements define what a system is supposed to do and non-functional requirements
define how a system is supposed to be.
Typically non-functional requirements fall into areas such as:

Accessibility
Capacity, current and forecast

Compliance
Documentation
Disaster recovery
Efficiency
Effectiveness
Extensibility
Fault tolerance
Interoperability
Maintainability
Privacy
Portability
Quality
Reliability
Resilience
Response time
Robustness
Scalability
Security
Stability
Supportability
Testability

3.
Use case diagrams - what they are and why use them
A use case diagram at its simplest is a representation of a user's interaction with the system and depicting the
specifications of a use case. A use case diagram can portray the different types of users of a system and the
various ways that they interact with the system. This type of diagram is typically used in conjunction with the
textual use case and will often be accompanied by other types of diagrams as well.

While a use case itself might drill into a lot of detail about every possibility, a use-case diagram can help
provide a higher-level view of the system. It has been said before that "Use case diagrams are the blueprints for
your system".[1] They provide the simplified and graphical representation of what the system must actually do.
Due to their simplistic nature, use case diagrams can be a good communication tool for stakeholders. The
drawings attempt to mimic the real world and provide a view for the stakeholder to understand how the system
is going to be designed. Siau and Lee conducted research to determine if there was a valid situation for use case
diagrams at all or if they were unnecessary. What was found was that the use case diagrams conveyed the intent
of the system in a more simplified manner to stakeholders and that they were "interpreted more completely than
class diagrams".[2]
The purpose of the use case diagrams is simply to provide the high level view of the system and convey the
requirements in layman's terms for the stakeholders. Additional diagrams and documentation can be used to
provide a complete functional and technical view of the system.

4.

Characteristics of good user stories.

Independent
Negotiable
Valuable
Estimable
Sized appropriately
Testable
5.

Fibonacci sequence and why it is used in story pointing

A popular scale used for story point estimating is the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55
That is why we use this scale; the numbers are generated by taking the sum of the last 2 numbers
Sometimes the following descriptions are attached to the numbers: 1: smallest, 2: small, 3: medium, 5:
medium-large, 8: large, 13: very large...etc. (stay mostly in the 1-13 range)
If your story point estimate is greater than 13, its an epic story that s/b broken down into smaller stories.
The numbers are generated by taking the sum of the last 2 numbers
Complexity is not linear, it goes up exponentially
6.

7.

Scrum Master Responsibilities

Answer

Facilitating the teams progress toward the goal: Scrum/Agile Masters are trained as team
facilitators and are constantly engaged in challenging the old norms of development while keeping the
team focused on the goals of the iteration.

Leading the teams efforts in continuous improvement: This includes helping the team improve,
helping the team take responsibility for their actions, and helping the team become problem solvers for
themselves.

Enforcing the rules of the agile process: The rules of agile are lightweight and flexible, but they are
rules nonetheless, and this role is responsible for reinforcing the rules with the team.

Eliminating impediments: Many blocking issues will be beyond the teams authority or will require
support from other teams. This role actively addresses these issues so that the team can remain focused
on achieving the objectives of the iteration.

Explain what a release plan is.

Answer:
The purpose of the Release Planning Meeting is to have everyone in the team understand and commit to
delivering the agreed release by the agreed date. Those present at a release planning meeting include the
product owner plus any other stakeholders that can add valuable input, the developers and testers, and
the scrum master.

Welcome, Introductions, Agenda, Meeting Goals, Ground Rules, Parking Lot, Consensus
Product Vision explanation by the Product Owner
Create a Backlog of Stories
Determine iteration length
Determine project level definition of done.

8.

Give points to stories

Discuss and Document what needs to be done in iteration 0
Determine Story Priorities 0 Product owner needs to pick!
Determine dependencies
Create a Release Plan
Team slots the stories in iterations
Common characteristics of projects
Project is that planning in which we try to best under a perfect system for making product or buying any
fixed asset or creating services for our customers.
Characteristics of a Project
1. Any project will have a start date and end date
it is the main feature of project that it has a start date and end date. Because if we increase the time of
completing of any business project, cost of project will increase. So, it is necessary to fix the time for
completing any project.
2. Project For Results
All projects are made for getting some result. Projects are always completed and we get new thing after
completing of project.
3. Projects differ from operations
Operations are different from project. Operations are day to day work and for this we can use operation
costing but project is big plan for doing any major construction.
4. A project usually needs resources to deliver its results
With getting resources for completing project, it will be very tough to complete the project and bring result
in the front of manager.
5. Major projects can be divided into subprojects
All major projects can be divided into subprojects. Suppose, you have to construct a building. For making
building, you have to take subproject for digging the earth or make a structure according to the height of
building

9.

PMIs (Project Management Institute's) project areas and what each means.
Answer:
Scope management defining and managing all the work required to successfully complete the project

10.
11.

12.

Time management estimating how long it will take to complete the work, developing an acceptable
project schedule, and ensuring timely completion of the project.
Cost management preparing and managing the budget for the project
Quality management Ensuring the project will satisfy the stated or implied needs for which it was
undertaken
Human resource management making effective use of the people involved with the project
Communications management generating, collecting, disseminating, and storing project information
Risk management identifying, analyzing, and responding to risk related to the project
Procurement management acquiring goods and services that are needed for a project from outside
the performing organization
Stages or phases in a typical waterfall project.
Water methodology.

Agile Manifesto
Answers:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software or new business processes.
Welcome changing requirements, even late in development. Agile processes harness change for the
customer's competitive advantage.
Working software is the primary measure of progress.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to
the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and
trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is
face-to-face conversation.
Agile processes promote sustainable development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly

13.
14.

Stories and story pointing

Iteration 0
During iteration 0, the team will be working on getting the environment setup. Getting this work done
in iteration 0 ensures that the entire team is dedicated to business stories and delivering values.
The meaning of done in iteration 0 is to get its major deliverables done. Some of its deliverables are:
The to-be process model.
Architecture Diagram, Data Models
High level user interface determines, Site Navigation
Release Planning Session complete
Environment setup (servers set up, initial database tables setup, any tools needed for developers are
installed and working)
Technology decisions made
-product backlog
-story estimation
-iteration backlog
- Environment Setup
- Architecture goals/ approach has been identified
- finalize team
-Gather Stories
-Prioritize stories according to business value and dependency
-Estimate the complexity of story using story points
-Estimate what will be done in iteration 1
-Build the Release Plan
15.

Fall through iteration

No new features added.
Testing of Features
Bug Fixes.
Execute Communication plan as you go live with a release.

16.

Story dependencies
Helps determine which stories need to be done before other stories.
Work with the Product Owner to Prioritize the Stories

17.

Problems with problems with traditional work effort forecasting by a project manager or lead
architect on a project.
Planning Poker game to create estimates
How do you determine initial velocity in an agile SCRUM project?
Velocity is a measure of how many story points a team can complete and get accepted as
Done after one iteration.
For a new team just starting you wont have access to real velocity yet.
Three ways to come up with initial velocity:

18.
19.

1. Use historical averages

2. Wait until you run at least one iteration
3. Forecast it
Ask the team, Which stories on the list do you think you can get done within the
first iteration?
Use the initial velocity as a starting point for developing your release plan.
20.
Iteration planning
21.
Iteration demonstration
22.
Typical makeup of a SCRUM Board
When practicing Scrum, we can make the sprint backlog visible by putting it on a Scrum task board.
Team members update the task board continuously throughout the sprint; if someone thinks of a new task (Test
the snark code on Windows 8.1), she writes a new card and puts it on the wall. Either during or before the daily
scrum, estimates are changed (up or down), and cards are moved around the board.

Each row on the Scrum board is a user story, which is the unit of work we encourage teams to use for their
product backlog. During the sprint planning meeting, the team selects the product backlog items they can
complete during the coming sprint. Each product backlog item is turned into multiple sprint backlog items. Each
of these is represented by one task card that is placed on the Scrumboard. Each task card starts on the Scrum
taskboard in the To Do column. The columns we generally use on a taskboard are:

Story: The story description (As a user we want to) shown on that row.

To Do: Place for all cards that are not in the Done or In Process columns for the current sprint.

Work In Process: Any card being worked on goes here. The programmer who chooses to work on it
moves it over when she's ready to start the task. Often, this happens during the daily scrum when someone says,
I'm going to work on the boojum today.

To Verify: A lot of tasks have corresponding test task cards. So, if there's a Code the boojum class
card, there is likely one or more task cards related to testing: Test the boojum, Write FitNesse tests for the

boojum, Write FitNesse fixture for the boojum, etc. Some task cards don't get corresponding test cards (Fix
Bug No. 321 in Bugzilla) so those are placed in the To Verify column.

Done: Cards pile up over here when they're done. They're removed at the end of the sprint. Sometimes
we remove some or all during a sprint if there are a lot of cards.

23.
Standup meeting - questions covered in this meeting, typical length, etc...
A stand-up meeting (or simply "stand-up") is a meeting with attendees typically standing. The discomfort of
standing for long periods helps to keep the meetings short.
Some software development methodologies foresee daily team-meeting to provide a status update to the team
members. The "semi-real-time" status allows participants to know about potential challenges as well as to
coordinate efforts to resolve difficult and/or time-consuming issues. It has particular value in Agile software
development processes,[1][2] such as Scrum, but can be utilized in any software development methodology.
The meetings are usually timeboxed to 515 minutes and are held standing up to remind people to keep the
meeting short and to-the-point.[3] The stand-up meeting is sometimes also referred to as the "stand-up",
"morning rollcall" or "daily scrum".
There are three questions to ask and answer in the daily stand-up.[4] Though it may not be practical to limit all
discussion to these three questions, the goal is to stick as closely as possible to these questions:
1. What did I accomplish yesterday?
2. What will I do today?
3. What obstacles are impeding my progress?
24.

Burn down chart

A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or
backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding
work. It is useful for predicting when all of the work will be completed. It is often used in agile software
development methodologies such as Scrum. However, burn down charts can be applied to any project
containing measurable progress over time.
Outstanding work can be represented in terms of either time or story points

A burn down chart for a completed iteration is shown above and can be read by knowing the following.

X-Axis

The project/iteration timeline

Y-Axis

The work that needs to be completed for the project. The time or story point estimates for the
work remaining will be represented by this axis.

Project Start
Point

This is the farthest point to the left of the chart and occurs at day 0 of the project/iteration.

Project End
Point

This is the point that is farthest to the right of the chart and occurs on the predicted last day of
the project/iteration

Ideal Work
Remaining
Line

This is a straight line that connects the start point to the end point. At the start point, the ideal
line shows the sum of the estimates for all the tasks (work) that needs to be completed. At the
end point, the ideal line intercepts the x-axis showing that there is no work left to be
completed. Some people take issue with calling this an "ideal" line, as it's not generally true
that the goal is to follow this line. This line is a mathematical calculation based on estimates,
and the estimates are more likely to be in error than the work. The goal of a burn down chart is
to display the progress toward completion and give an estimate on the likelihood of timely
completion.

Actual Work
Remaining
Line

This shows the actual work remaining. At the start point, the actual work remaining is the
same as the ideal work remaining but as time progresses, the actual work line fluctuates above
and below the ideal line depending on how effective the team is. In general, a new point is

added to this line each day of the project. Each day, the sum of the time or story point
estimates for work that was recently completed is subtracted from the last point in the line to
determine the next point.
Measuring performance
Actual Work Line is above If the actual work line is above the ideal work line, it means that there is more
the Ideal Work Line
work left than originally predicted and the project is behind schedule.

Actual Work Line is below If the actual work line is below the ideal work line, it means that there is less
the Ideal Work Line
work left than originally predicted and the project is ahead of schedule.

25.
Managing project impediments in an Agile SCRUM project
n Scrum, an impediment is anything that keeps a team from being productive. An impediment can literally be
anything, from a team member who is slacking to a freezing team room. But if its blocking the team from
performing to the best of its abilities, its an impediment.
To help maximize efficiency, the role of the ScrumMaster is completely dedicated to resolving impediments.
TheScrumMaster works in various capacities, including helping the Product Owner prepare the backlog and
ensuring that important Scrum artifacts are visible, but the ScrumMasters primary responsibility is to eliminate
impediments and facilitate a teams optimum performance. In this arrangement, it is the teams responsibility to
communicate what impediments are holding them back. This communication occurs each day in the daily
Scrum, when team members report on what theyve accomplished in the past 24 hours, what they plan to
accomplish in the next 24 hours, and what impediments obstruct them. Scrum systematizes feedback to ensure
that aScrumMaster always knows exactly what challenges are keeping the team from success and can work to
remove them.
Its also possible for impediments to apply to an organization, particularly in regard to Scrum. Just like a broken
keyboard, for instance, would prevent a team member from writing code, an organizational culture clash
obstructs a smooth Scrum adoption. In scenarios like this, a company needs an advocate inside the company to
help management recognize the benefits of Scrum. Basically, such an advocate would be acting like
aScrumMaster, removing barriers before a single Scrum team has been created. Still, even an organizational
Scrum advocate does not ensure that Scrum will stick. But, like the ScrumMaster who works closely with a
team to eliminate barriers, an internal Scrum advocate helps enact positive change and contributes toward a
successful Scrum adoption.

26.

Business Integration Model

Answer:
Organizations that can keep the components of the model in alignment are most successful.

27.

Value chain in a business or institution

Answer:
Value chain is the chain of activities, business perform in order to deliver a valuable product or service.
The idea is that has the product or service passes through each activity it gains some additional value.
Slide definition: core business processes and sub-processes
Examples: One is the value chain software developers use from obtaining customers need to delivering
a solution to the customer to match their needs. Another value chain is the process of producing specific
goods. The manufacturing from the beginning of a product to its finish product.

28.

Lean process improvement

Definition: A business approach based on the goal of eliminating waste and maximizing flow in
business processes.
Lean began as a methods of driving cost of out of auto manufacturing. Toyota has been a leading
user of the lean approach since the 1950s.
Goals: Henry Fords low cost, fast lead time, high Quality with GMs Variety of product
Focuses on the elimination of Waste.
Definition: A set of principles that accelerates the speed of all processes across an enterprise
Reduction is wastes leads to increased speed and reduced cost
29.
8 lean forms of waste
Lean concept of waste:
A set of principles that accelerates the speed of all processes across an enterprise
Reduction in wastes leads to increased speed and reduced cost.
Overproduction: To produce sooner, faster or in greater quantities than customer demand
Inventory: Raw Materials, work in progress or finished goods which is not having value added to it.
Waiting: People or parts that wait for work cycle to be completed
Motion: unnecessary movement of people or parts in a process
Transportation: unnecessary movement of people or parts between processes
Rework: Not done right the first time. Repetition or Correction of a Process
Over processing: Processing beyond the standard required by the customer

Intellect: any failure to fully utilize the time and talent of people
30.

Kaizen
KAI means 'change' or 'the action to correct'.
ZEN means 'good
Kaizen is a change for the good
Kaizen Event: Kaizen is an approach to continuous process improvement. It is a way of thinking and
behaving. It is about unleashing the creative power of people actually doing the work, in order to design
more effective and efficient processes.
Valuable: Because you will have complete understanding of the current performance, figure out what is
waste with current process, analyses gaps and define better process, improve current process and
measure the changes for success

31.

Kaizen principles
Say no to status quo, implement new methods and assume they will work
If something is wrong, correct it
Accept no excuses and make things happen
Improve everything continuously
Abolish old, traditional concepts
Be economical. Save money through small improvements and spend the saved money on further
improvements
Empower everyone to take part in problems' solving
Before making decisions, ask "why" five times to get to the root cause. (5 Why Method)
Get information and opinions from multiple people
Remember that improvement has no limits. Never stop trying to improve Continuous improvement

32.

Kaizen event
Are formalized activities that organizations use to achieve rapid and dramatic improvements and
progressively shift their culture.
The kaizen event may be a few days to a few weeks at the most to
Determine the current state of a process (baseline)
Describe the problems
Agree on a future state
Conduct experiments to determine the future state can be achieved by the improvements
Define and accomplish the quick wins to gain most of the benefits
Add remaining tasks to a backlog to achieve continuous improvement
Why Do a kaizen Event? Establish, change and improve a process.

Steps in the Kaizen process

Define Process Problem
Measure Current Performance
Identify Waste in Current Process
Conduct Gap & Root Cause Analysis
Define Should-Be Process
Develop Measurements for Success

33.

34.

Improve Current Process

Standardize Operating Procedures
Develop 60 Day Action Plan

Voice of the customer and how to obtain this. **

Answer:
Interviews
Customer Observation
Surveys
Competitive Benchmarks
Be A Customer
Focus Groups

35.

Value add, non-value add and required non-value add steps

To provide any product or service, you have to use resources like money, materials, labor, time, and
information. The goal is to provide the greatest amount of value to customers while utilizing the least amount
of your resources. This idea of adding value to products and services is a key concept of Lean. It is defined as
anything for which the customer would be willing to pay. If what you are providing is not something the
customer would be willing to pay you for, then you are not providing value to the customer.
Any time you begin analyzing a process, you want to look at each step and determine if it is contributing to the
value of the desired output. Each step can be classified into one of three categories:

Value-added

Non-value added, but necessary

Non-value added (waste)

Value-Added Steps
Value added steps in a process are those in which you add something to a product or service for which the
customer would be willing to pay. These activities are where you gain the most from expending your resources
when providing a product or service. Take the Sun Card, for example. There are several steps in the process for
applying for and receiving a Sun Card, but the customer is only willing to pay for the physical card with their
name, ID number, and photo on it. In this case, only those steps in the process that contribute to the actual
creation of the card would be considered value added steps.
Non-Value Added But Necessary Steps
Just because a process step is not value-added does not mean it is a bad thing. Processes all include steps that
do not add value, but are necessary to make the product or service happen. It has been my experience that the
majority of activities in service processes fall into this category. They do use resources, so you want to reduce
the amount of non-value added work whenever possible. Often, this type of activity fulfills some sort of
administrative purpose such as enabling value added steps, maintaining organizational records, or meeting legal
or regulatory requirements.
Looking at the Sun Card example, when a person wants a Sun Card they must fill out an application. As far as
the customer is concerned, this is a non-value added step because it does not directly result in the creation of the
physical card itself and they would not be willing to pay to fill out a form. This step is necessary because it
enables the Sun Card staff to start the process, verify that the customer is eligible to receive a Sun Card, and

locate their information in ASUs database. Without this step, the creation of the physical card would not be
able to happen.
Non-Value Added Steps (Waste)
The third category that process steps can fall into is pure waste. In these steps resources are expended, delays
occur, and no value is added to the product or service. Customers are absolutely not willing to pay for these
activities. These steps should be eliminated from the process. The Sun Card process does not contain any pure
waste steps.
36.
SIPOC
SIPOC: In process improvement, a SIPOC is tool which summarizes inputs and outputs of one or more
processes into a tabular form:
SIPOC:
S: Suppliers: Suppliers of work may be external or internal
I: Inputs Products, information or other information related to a process
P: processes
Steps used to go from inputs to the outputs includes value added work and no value add work
O: Outputs
The outcome such as service provided or product provided ensures you meet Critical to Quality measures
C: Customer Customers of the process
37.
38.

Total Lead time

Value added time
Lead time is how long it takes for you to deliver your service or product once the order is
triggered.
Littles Law
Lead Time = ____Amount of Work-In Process____
Average Completion Rate
The idea is that you dont have to track an item to know lead time, so long as you know how many items
you are working on and how often you finish one of them
39.
Swim lane value stream map
Value stream mapping is a lean manufacturing technique used to analyses and design the flow of
materials and the information needed to bring a product or service to a customer.
Swim lane is a convenient way to show tasks that move from one department to other. And can also
illustrate the current state and future state
Add key metric such as lead times and value added times for each task.

40.

Work in Process (WIP)

Means the work that is needed to be done, or which is incomplete.
Work in process sound like manufacturing, but we should think of them as things in process (TIP). This
includes the phone call you have to return, checks waiting to be processed, and applications for loans or
insurance that need to be processed.

41.

Delays/ Queue Time: If you have WIP, you have work that is waiting to be worked on. Any time that
work sits in a queue you can consider that a delay.

Process Cycle Efficiency (PCE)

Calculation of process cycle efficiency
Most processes are un-lean. 50% or more of work is non-value add.

Process Cycle Efficiency (PCE) is usually less than 10%.

PCE =

42.

___Value-Add Time____
Total Lead Time
To improve this:

Look for non-value added work and eliminate whenever possible.

Reduce the lead time

Lead time and littles Law

Lead time is how long it takes for you to deliver your service or product once the order is triggered.
Littles Law
Lead Time = ____Amount of Work-In Process____
Average Completion Rate
The idea is that you dont have to track an item to know lead time, so long as you know how many items
you are working on and how often you finish one of them.
In queueing theory, a discipline within the mathematical theory of probability, Little's
result, theorem, lemma, law or formula[1][2] is a theorem by John Little which states:
The long-term average number of customers in a stable system L is equal to the long-term average effective
arrival rate, , multiplied by the (Palm-) average time a customer spends in the system, W; or expressed
algebraically: L = W.

43.

Pull System
Answer:
Pull system is an effective mechanism using which we can reduce Work In
Process and hence the lead times (or associated costs of delivery of goods and services) as and when
required by customers. Its implemented using a Kanban system.
Pull System vs. Typical ways:
Minimization of waste
Reduction of WIP and stock
Flexibility to deliver customer demands
Reduction in the need of working capital
Pull System: Pull Systems/Kanban control the flow of resources in a production process by replacing only
what has been consumed. They are customer order-driven production schedules based on actual demand
and consumption rather than forecasting. Implementing Pull Systems can help you eliminate waste in
handling, storing, and getting your product to the customer.

In non-customer-facing processes, WIP can be reduced by using a Pull system.

In any operation that doesnt deal directly with customers that is, where WIP is orders or calls or
emails or reports, not people controlling WIP is much easier than improving completion rate.

Whenever, and wherever possible, limit how much work goes into a process queue at a given time.

Work released into pull systems in a service environment means making deliberate decisions about
timing of work released into a process For example, you may want to triage bid opportunities based on

Difficulty of bid

Gross Profit dollars

Competitive advantage

Keys to create effective pull system.

44.

Identify/confirm the service level you want to achieve (ask your customers about this)
Determine your work groups completion rate.
Use Littles law to determine WIP.
Cap active work in the process to the maximum WIP.
Put all work in the incoming buffer
Develop a triage system for determining which incoming work should be released into the process.
Continue with other process improvements so you can improve completion rates and further reduce lead
time.
Use a Kanban board with WIP limits to limit work in process.
Kanban
Answer:
Is a scheduling system for lean and just-in-time (JIT) production?[2] Kanban is a system to control
the logistical chain from a production point of view, and is not an inventory control system

3 rules of Kanban
Strict Queue Limits
Pull Value Through
Make it Visible
45.

Kanban board
Kan means "visual"
ban means "card" or "board
A signaling system to trigger action
Uses cards to signal the need for work to be done
Toyota Lean lesson focusing on Just in Time production
Example: 20 car doors, 5 left = time to make more doors
Doors are requirements, requirements are inventory

46.
Hidden Factories
Hidden factories: costly sub-processes that were put in place due to a problem that occurred years ago that
has not recurred. Adds waiting time to the current process and maybe some resources too.

47.
48.

49.

Pareto chart as it relates to analyzing the vale stream map.

Value of mockups and prototyping in projects
Answer:
Mockups
Generate ideas quickly; review and iterate sooner
Communicate easily with designers, developers, and product managers
Iterate in real time with your stakeholders
Can be used as requirements and user stories documentation
Pictures and prototyping tools plays a major role in minimizing the documentations. Its
encouraged to take screenshots rather than creating complex Visio diagrams. Also, functional
mockups combined with short written stories are good for developers during the development
process.
Acceptance testing
As a customer, I always see current energy pricing reflecting on my portal and on premise devices so that I
know that my energy usage costs are accurate and reflect any utility pricing changes
Acceptance Test:
Verify the current pricing is always used and calculated numbers are displayed correctly on the
portal and each on premise device
Verify the pricing and the calculated numbers are updated correctly when the price changes
Verify the current price field itself is updated according to the scheduled time
Verify the info/error messages when there is a fault in the pricing

50.
51.

Functional test and functional test plan

Load testing
Load Testing tests Stability, Performance and Functionality under the Load.
Load testing is the process of putting demand on a system or device and measuring its response. Load
testing is performed to determine a systems behavior under both normal and anticipated peak load
conditions. It helps to identify the maximum operating capacity of an application as well as any
bottlenecks and determine which element is causing degradation.

Identify and fix problems prior to production implementation.

Statistics on applications

During initial load test

Web applications fail at approximately 10% of the expected workload.

Rising Expectations: Internet Time

8 seconds --> 4 seconds --> 2 seconds --> POP

Use virtual tools to simulate hundred or even thousands of possible users to save on costs.
52.
Test driven development
The test driven development prevent defects from getting into the code base in the first place and minimize
waste.
Build Tests to prevent defects

Write unit test cases first. Code second.

Can take 15% - 20% effort initially

Defects -- 90% lower rates

Source: Gartner
Unit tests can be combined into Test Suites which can be used in Continuous
Integration testing
Ideal for core part of applications
Difficult areas for TDD
Workflow and process
Data from legacy systems
User Interfaces

Pitfall
Misinterpret the requirement, misinterpret the test case, and catch in Acceptance Testing.
53.

Continuous integration

Continuous integration implements continuous processes of applying quality control small pieces of
effort, applied frequently
The continuous integration is the process where
Developers should commit all changes at least once a day (once per feature built / each unit test case passed),
It is counter intuitive for developers to check in their code frequently; their instincts are to make sure that an
entire task is complete before making it public.
The system should be built (compiled) as soon as code is checked in.

1.
2.
3.
4.

The four main process on continuous integration are

Watch - watch for changes checked into the source code repository.
Build - The system should be built (compiled) as soon as code is checked in.
Test - perform test scripts against the current code. Ideally this should be automated. Manual smoke test can
also be done.
Publish - notify the team of success or failures of the build and subsequent test. Any failures should be fixed as
soon as possible.