● (SAIC) won the bid and created a classic waterfall project
○ $400 Million + $78 Million Additional Funding
○ 300 person team for Requirements + 6 months = 600 pages of listed
○ 700,000 lines of program code
● 4 Years with no Result
● Lockheed Martin wins the new ‘Sentinel’ system a.k.a project 3 years 2006 to 2009.
The total project budget was $425M.
a) $305M was budgeted for Lockheed Martin.
b) $120M was allocated for the FBI to run a massive program office to carry out
detailed and prescriptive oversight of the work
● Abandoned after 3 years
● FBI CIO took over, hire Scrum Expert (Jeff Johnson)
● 220 person team reduced to 40
● 18 months completed
FBI VCF (Virtual Case File)
FBI VCF (Virtual Case File) - LESSON LEARNED
Agile SDLC gets things done.
incremental approach would be faster because
functionality would be developed, and adjustments
made, in two-week "sprints."
he FBI learned that lesson the hard way in October
when the system, during a four-hour test involving
743 users, suffered two outages. The agency made
the mistake of running the test on legacy hardware.
Don't deploy new software on old
Sentinel came in under its $451 million budget. The
caveat is that the FBI's original cost estimate for
Sentinel was $425 million, it stayed under budget
when changed to Scrum.
Agile SDLC is relatively cheaper
Initially start with custom coding and systems
integration involved. Couple of services changed to
EMC's Documentum document management
software, Oracle databases, IBM's WebSphere
middleware, Microsoft's SharePoint, and Entrust's
Commercial software plays an
TRADITIONAL vs AGILE SDLC
Incremental vs Iterative
Incremental development is a development approach
that slices the product into fully working slices that
are called increments.
Iterative development is when teams gradually build
up the features and functions but don’t wait until
each of these is complete before releasing.
Traditional phase requires different amounts of time
and the involvement of different people. The time
needed will depend on the project, but you will never
see a balanced amount of time spent on each phase.
The agile interpretation of SDLC uses a different unit
of work: Sprints. A sprint is a time-box for completing
a body of work. It has a consistent duration
regardless of the work.
Sprints vs Phases
A traditional view of SDLC isn’t flexible. During the
development process, new findings don’t get
incorporated into previous steps.
The more agile view of SDLC, however, is flexible.
With frequent change anticipated, you can introduce
a brand new body of work in the next sprint that
bears no relation to the previous sprint’s work.
Change is less expensive.
Tracking a project managed with waterfall is
relatively straightforward. Any given project will be in
one of seven phases at any given time.
Agile doesn’t use the term project in the same way.
With this approach, a single team is generally
working on a specific product or a service, but might
have several projects on their plate at the same time.
AGILE MANIFESTO / VALUES
That is, while there is value in the items on
the right, we value the items on the left more.
1 Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
2 Welcome changing requirements, even
late in development. Agile processes harness
change for the customer's competitive
3 Deliver working software frequently,
from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
4 Business people and developers must work
together daily throughout the project.
5 Build projects around motivated
individuals. Give them the environment and
support they need, and trust them to get the
6 The most efficient and effective method of
conveying information to and within a
development team is face-to-face
7 Working software is the primary measure
8 Agile processes promote sustainable
development. The sponsors, developers, and
users should be able to maintain a constant
9 Continuous attention to technical
excellence and good design enhances agility.
10 Simplicity -- the art of maximizing the
amount of work not done--is essential.
11 The best architectures, requirements,
and designs emerge from self-organizing
12 At regular intervals, the team reflects
on how to become more effective, then tunes
and adjusts its behavior accordingly.
Agile generally promote a
management process that
inspection and adaptation.
scrum is only one of ragile
Assign the role of
Small Is Best - Time,
Scope and Team
The project was
small, both in terms
of scope and the
number of people
Scope was fixed and
relatively small and
was kept this way
higher chance of
a person in team who
will look after the
product users but
also the business
Apply the necessary
changes in the
workflow or even the
meetings to discuss
goals & update the
team about all the
important things they
need to keep in mind
It’s smart to meet up
at the end of every
week to show what
each team member
has done and review
all the the things
BEING AGILE WITHOUT SCRUM
POPULAR AGILE FRAMEWORKS
fairly structured process that
involves self-organized teams
who commit to specific
deliverables, meet daily and
break their work into iterations.
goal-oriented; you set a goal for
the team, they work until that goal
is completed, and you iterate on
adaptation of lean manufacturing
principles, and primarily focuses
on limiting the amount of work-in-
progress to facilitate high-quality
development team can be comprised of all kinds of people including designers, writers,
● Delivering the work through the sprint.
● To ensure transparency during the sprint they meet daily at the daily scrum
The business is represented by the product owner who tells the development what is
important to deliver.
● Managing the scrum backlog
● Release management
● Stakeholder management
gluing everything together and ensuring that scrum is being done well.
● Self Organization
The product backlog is a list of
new features, enhancements, bug
fixes, tasks, or work requirements
needed to build a product.
It’s compiled from input sources
like customer support, competitor
analysis, market demands, and
general business analysis.
The sprint backlog is a set of
product backlog tasks that have
been promoted to be developed
during the next product
Sprint backlogs are created by
the development teams to plan
deliverables for future increments
and detail the work required to
create the increment.
A product increment is the
customer deliverables that were
produced by completing product
backlog tasks during a sprint. It
also includes the increments of all
● Attendees: Development team, scrum master, product owner
● When: At the beginning of a sprint.
● Duration: Usually up to two hours per week of iteration. e.g. a two-week sprint kicks off with a four-hour
● Purpose: Sprint planning sets up the entire team for success throughout the sprint.
○ Coming into the meeting, the product owner will have a prioritized product backlog. Use the sprint
planning meeting to flesh out intimate details of the work that needs to get done.
○ Encourage team members to sketch out tasks for all stories, bugs, and tasks that come into the sprint.
● Attendees: Development team, scrum master, product owner
● When: Once per day, typically in the morning.
● Duration: No more than 15 minutes.
○ Don't book a conference room and conduct the stand up sitting down.
○ Standing up helps keep the meeting short!
● Purpose: Stand-up is designed to quickly inform everyone of what's going on across the team. It's not a
detailed status meeting.
○ What did I complete yesterday?
○ What will I work on today?
○ Am I blocked by anything?
● Attendees: Development team, scrum master, product owner, Product Stakeholders (optional)
● When: At the end of a sprint or milestone.
● Duration: Typically 60 minutes per week of iteration-e.g. a two-hour review following a two-week sprint.
● Purpose: Sprint review is a time to showcase the work of the team.
○ time for the team to celebrate their accomplishments
○ demonstrate work finished within the iteration
○ get immediate feedback from project stakeholders
● Attendees: Development team, scrum master, product owner
● When: At the end of an iteration.
● Duration: Typically 45 minutes per week of iteration-e.g. a 90-minute retrospective after a two-week sprint.
● Purpose: Agile is about getting rapid feedback to make the product and development culture better.
Retrospectives help the team understand what worked well–and what didn't.
Epic & User
Story Points Burn Down Velocity &
DOR & DOD
It is a short and clear
description of feature, that
will give user (minimal)
Story point is a tool for
It estimates the effort to
make a task done from 3
points: time, complexity
DOR or Definition of
ready and DOD or
Definition of Done are
the checklists useful for
understanding the work
a line chart drawn
between remaining work
average & future team
performance in story
SCRUM IMPORTANT CONCEPTS
🧑 🧑 📋 📈 🧑
USER STORY EPIC
have a lifespan of multiple sprints and cannot be considered
complete until all stories based on them are also complete.
As a: content-contributor
I want to: categorize the content I create
So I can: ensure that readers can easily locate it
It is a short and clear description of feature, that will
give user (minimal) real value.
most granular description of functionality. Stories describe
deliverables that can be completed in a single sprint.
As a: experienced-end-user
I want to: Save my work using a command-key sequence
So I can: Quickly save my work without multiple clicks
STORY POINTS Measurement
Typical be done in Fibonacci sequence 1, 2, 3, 5, 8 or in T-
Shirt sizes S, M, L, XL
Story point is a tool for relative estimation. It estimates
the effort to make a task done from 3 points: time,
complexity and uncertainty.
Story points vs Mandays
● Relative Story Point estimates are quicker and easier to do.
Estimating directly in man-days often leads us to get into
too much detailed thinking.
● The team often cannot agree on them because they depend
upon the speed with which people will do the work
● If the team changes the way that they are working (for
example, perhaps they are going to start automating their
testing) then if they have estimated in man-days, they will
have to re-estimate every item
Planning poker, also called Scrum poker, is a consensus-based,
gamified technique for estimating, mostly used to estimate effort
or relative size of development goals in software development.
In backlog refinement the team looks one or two sprints out to see what is coming up and prepares
these stories to be brought into a sprint. Estimation is a common thing to happen here because the
act of trying to estimate the story often brings out details about the story.
This is a planning that takes a high-level look at the next few months and I've worked with many
teams that take a first-guess estimate at all stories in the release planning. It is understood in these
teams that these estimates are rough guesses used for general planning purposes and they usually
revisit the estimates in a Backlog Refinement closer to actually working the item.
It isn't common practice anymore to estimate right at sprint planning, but it still happens sometimes.
Usually, this happens with stories that emerge right before the sprint (maybe a gap discovered in the
last Sprint Review). This estimate is usually done at this time in order to weigh the cost/value benefit
before deciding to bring it into the sprint.
WHEN TO ASSIGN STORY POINT ?
● The conditions of satisfaction have been fully identified
for the story.
● The story has been estimated and is under a certain
size. For example, if the team is using story points, a
team might pick a number of points and only allow
stories of that size or smaller into the iteration. Often this
maximum size is around half of the team’s velocity.
● The team’s user interface designer has mocked up, or
even fully designed, any screens affected by the story.
● All external dependencies have been resolved, whether
the dependency was on another team or on an outside
Definition of ready a set of agreements that lets
everyone know when something is ready to pick up,
e.g., when a user story is ready to be taken into a sprint
Definition of Done is an agreed-upon set of items that
must be completed before a project or user story can
be considered complete.
● Code is peer-reviewed
● Code is deployed to test environment
● Code/feature passes regression testing
● Code/feature passes smoke testing
● Code is documented
● Help documentation is updated
● Feature is OK’d by stakeholders
● provides an updated status report on the progress of the
● visual representation of this most important data keeps
everyone on the same page
● encourages the team to deal with issues before they
● relies on good estimates & discipline
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.
● If you notice that the team consistently finishes work early,
this might be a sign that they aren't committing to enough
work during sprint planning.
● If they consistently miss their forecast, this might be a
sign that they've committed to too much work.
● If the burndown chart shows a sharp drop during the
sprint, this might be a sign that work has not been
estimated accurately, or broken down properly.
1. Epic menu: Select which epic to view data
2. Work added: The dark blue segment shows
the amount of work added to the epic in each
sprint. In this example, work is measured in
3. Work remaining: The light blue segment
shows the amount of work remaining in the
4. Work completed: The green segment
represents how much work is completed for
the epic in each sprint.
5. Projected completion: The report projects
how many sprints it will take to complete the
epic, based on the team's velocity.
Velocity & Capacity
Velocity is an average team performance in story
points based on previous sprints statistics.
Capacity is future team performance in story points
based on the team’s availability — there may be an extra
holiday next sprint or someone will go on vacation.
Visual Signals Columns Commitment
visual cards (stickies,
tickets, or otherwise).
Kanban teams write all of
their projects and work
items onto cards, usually
one per card.
For agile teams, each
card could encapsulate
one user story.
Each column represents a
specific activity that
together compose a
Cards flow through the
workflow until completion.
Workflows can be as
simple as “To Do,” “In
Progress,” “Complete,” or
much more complex.
maximum number of
cards that can be in one
column at any given time.
A column with a WIP limit
of three cannot have
more than three cards in
The commitment point is
the moment when an idea
is picked up by the team
and work starts on the
Delivery point is when the
product or service is in
the hands of the
KANBAN 5 COMPONENTS
VIEW IMPORTANT DETAILS AT A
Each kanban card typically features a brief description of a
work item, along with its owner, due date, and status. The card
can include other information, like pointers to source
documentation or a list of issues blocking the item's progress.
kanban card represents a single work item as it moves
through various stages of completion which are
represented onkanban board.
HAND OFF DELIVERABLES
SMOOTHLY AND EFFICIENTLY
Kanban cards encourage teams to establish clear and
consistent expectations for each functional area.
Kanban cards make it easy to keep track of lead time, which is
the time it takes for a work item to go from start to finish.
Kanban cards, together with a kanban board, can help teams
identify bottlenecks in their workflow and streamline their
Follow us on Instagram @lifeatmekari and LinkedIn “Mekari” for info on our next events and
updated job vacancy (monthly)
Visit our career page at mekari.com/careers to explore more opportunities with Mekari