Scrum & Kanban in nutshell, template is useful for small team with any collaboration tools. Scrum masters products owners & agile teams can use this tool/template for better collaboration. intention are to spread agile awareness. please maintain the santity. this should be used as commercial gains. This template are results of empiricism culture initiated by experts in the agile sector.

1. Scrum in a Nutshell
Roles Scrum Master(SM): Product Owner (PO) : Developers
Artifacts Product backlog - Input Sprint Backlog - Activity Increments - Outcome
Commitment Product Goal Sprint Goal Definition of Done
Product
backlog
Items (PBI)
Business Requirements
(Hypothesis)
1. Features
A. User stories (functional)
B. Enabler stories
(technical/Spikes/NFR's)
Day 1:
Event: Sprint planning,
Duration: <4hrs per 2 week sprint.
Every day
Event: Daily
scrum
Duration: <15
mins
Day 10: Sprint review
Event: Sprint Review
Duration: <2 hrs per
2 week sprint
Day 10:
Event: Sprint
retrospective
Duration: <1.5 hours per 2
week sprint
An Increment is a concrete stepping stone toward the
Product Goal.
Multiple Increments may be created within a Sprint
Outcome
Definition of Ready (DoR): The stories at the
top of the Product Backlog that the Team will be pulling into the
Sprint Backlog, must be Ready
Prirotization (MoSCoW rule - Best
practice)
Must have to requirements
Should have if, there is possibility
Could have but not very critical
Will not be required now
Definition of ready : Stories immediately
actionable.
Sprint backlog items : Items pulled from PB
Sprint planning: Story points, Velocity, Risk
(impediments) & dependency.
Plan the progress
on daily basis
Create
transperency on
dependency &
impediments
Build cross
functional
capabilities.
Inspect the outcome
and Adjust based on
the feedback by the
stakeholder
Plan ways to increase
quality and effectiveness.
Assumptions that led them
astray are identified and
their origins explored.
The Scrum Team inspects
how the last Sprint went
with regards to individuals,
interactions, processes,
tools, and their Definition of
Done
The Definition of Done is a formal description of the state
of the Increment when it meets the quality measures
required for the product.
The moment a Product Backlog item meets the Definition
of Done, an Increment is born.
The Definition of Done creates transparency by providing
everyone a shared understanding of what work was
completed as part of the Increment
If a Product Backlog item does not meet the Definition of
Done, it cannot be released or even presented at the
Sprint Review. Instead, it returns to the Product Backlog
for future consideration.
Responsible
Product Owner has content authority on
Product backlog & commit to product goal
Product Owner needs prioritize the the PBI's
Product Owner need fulfill teams pre-requiste
(ask) in form of DoR.
Product Owner to define acceptance criteria
(BDD can be used as Best practice)
Team to decide the item to pulled from the
prioritised PBI
Team has the content authority of Spritn backlog
Team to self organise and assign and plan the
implementation.
Scrum master to enact SCRUM
Scrum master to facilitate event
Scrum master to resolve impediments, risk and
dependency
Scrum master to foster agile work enviroment.
Scrum master to mentor and guide team.
Scrum master to remove organization impediments.
Team is responsible for
attending & plan the
progress on daily basis.
Scrum master to
facilitate (if required) and
Mentor the team.
Scrum. Master to track
the impediment and take
it to closure.
Team to provide the
outcome and limit the
presentation
Stakeholder to provide
the feedback
The Scrum Team discusses
what went well during the
Sprint, what problems it
encountered, and how
those problems were (or
were not) solved.
Scrum master to faciliate
the event
If the Definition of Done for an increment is part of the standards of the
organization, all Scrum Teams must follow it as a minimum. If it is not an
organizational standard, the Scrum Team must create a Definition of Done
appropriate for the product.
The Developers are required to conform to the Definition of Done. If there
are multiple Scrum Teams working together on a product, they must
mutually define and comply with the same Definition of Done.
Metrcis Customer user satisfaction Gap On product Index
Time spent on context switiching
Velocity
Lead time
Burn down chart
Defect trends
Build and Integration
frequency.
Time to learn
Innovation rate
Customer Satisfaction
Empolyee satisfaction
Product to cost ratio
Customer usage index

2. Kanban: Visualize the flow and Manage WIP limit
State New Requirement Development QA testing UAT Testing PROD
Buffer Analysis Freezed Inprogress / Bug fixing Peer review (Unit testing) Deploy Release
WIP Limit - e.g 100 5 5 15 25 30 10 5 3 2
Class
Expedite
-
+5%
Fixed
date
-
60%
Standard
-
30%
Tangible
-
10%
Popular Metrics Through put, Flow velocity, Flow efficency, Flow distribution, Flow time
Checkpoint Prerequisites/Exit conditions to be met before moving item/tickets to next state
Expedite - +5%
Items/ tickets are taken on highest priority due to the impact it has caused on the application. Everybody will toegther to compelte it ASAP, rest all class will be on hold until the expedite is completed/fixed. Hence,
capcity allocation is additional 5% i.e overall 105% (Expedite 5% + sum of all the rest class 100%)
Fixed date - 60% Items/ tickets have predefined start date and end date. Hence, capacity allocation is 60% of the total WIP limit, in this example i.e 60 items/ticket distibuted across the states w.r.t each state's WIP limit
Standard - 30% Items/ tickets is worked based on first in and first out logic. Hence, capacity allocation is 30% of the total WIP limit, in this example i.e 30 items/ticket distibuted across the states w.r.t each state's WIP limit
Tangible - 10%
Items/ tickets is worked based on forecasted threat to the feature or application, but not an immediate need Hence, capacity allocation is 10% of the total WIP limit, in this example i.e 10 items/ticket distributed across
the states w.r.t each state's WIP limit