Scrum With KANBAN can be described as below
Utilization Thinking to Flow based Thinking
Scrum's structure and Kanban's flow-based principles work together to streamline agile projects. Lets see how it is getting managed and measured.
Content
1. Product Backlog
The Product Backlog represents a prioritized list of features, tasks, or user stories that need to be completed to improve or build the product. Items in the Product Backlog, such as PBL1, PBL2, etc., are ideas or requirements yet to be developed. These backlog items are selected based on priority, customer feedback, and business value.
Example: Imagine a mobile app development project where the Product Backlog includes features like "User Authentication," "Profile Management," and "Notification System." Each feature is prioritized based on user needs and business value.
Product Backlog Refinement <= 10% capacity of sprint team
2. Sprint Backlog
The Sprint Backlog is a subset of the Product Backlog. It contains items that the team commits to completing during a specific sprint. Each sprint represents a time-boxed period (usually two weeks) in which the team focuses on a set of tasks from the Sprint Backlog.
Example: For a sprint focusing on user account management, items such as "Create login API," "Implement user registration," and "Add password reset functionality" might be selected from the Product Backlog and added to the Sprint Backlog.
3. Work-In-Progress (WIP)
All discrete units of customer value entered but not exited
Average Cycle Time: Calculated by dividing Average WIP by Average Throughput. It indicates the estimated time for current tasks to complete.
WIP Helps in following way:
Value is realised more quickly
Lead to more sustainable pace
Shorter feedback loops
Collaboration increases
WIP Limits:
WIP limits to control the number of tasks that can be in each stage of the process simultaneously. For example, the To Do column has a WIP limit of 5, meaning no more than five tasks should be in this stage at once. Dev has a WIP limit of 3, and Testing has a WIP limit of 2.
WIP limits help teams focus on completing tasks rather than overloading the workflow with too many items. This prevents bottlenecks and ensures smoother progress.
Example: If three tasks are already in development, no additional tasks should enter this stage until one task is completed and moves to the next column. This encourages team members to finish work in progress rather than starting new tasks prematurely.
4. Work Item Age (WIA)
The time that has pass since a work item as started until the current time
Average Items in Queue: Calculated by multiplying Arrival Rate and Wait Time. This can predict potential backlog bottlenecks.
5. Kanban Columns: To Do, Dev, Testing, and Done
The columns in the workflow represent stages that tasks go through from start to finish.
To Do: Items from the Sprint Backlog that are ready to be worked on.
Dev: Tasks actively being developed.
Testing: Tasks undergoing testing.
Done: Tasks that have been completed and meet the Definition of Done (DoD).
Example: A task, "Add user profile page," might start in To Do, then move to Dev for coding, proceed to Testing for quality assurance, and finally be marked as Done once it passes all tests and meets acceptance criteria.
6. Key Metrics
Cycle Time: The time taken for an item to move from Entry (when it begins work) to Exit (when it is completed). This metric shows how quickly tasks are completed on average.
This Assess efficiency of work ie., start of work to completion of it
Total time a task spends in progress stages.
Amount of elapsed time that a Work Item spend in WIP mode
Example: If a task enters To Do on Monday and reaches Done by Thursday, its cycle time is four days.
Cycle Time = InProgress + Review + Done Cycle Time = ToDo + Dev + Test + Done
Lead Time: The total time from when an item enters the Product Backlog until it reaches Done.
Lead time includes waiting and processing times.
Responsiveness of end-to-end process ie., Request To delivery (Including Waiting time)
Total time from Product Backlog to completion.
Example: If a feature was added to the Product Backlog three weeks ago and is completed today, its lead time is three weeks.
Lead Time = Sprint Backlog + InProgress + Review + Done Lead Time = Sprint Backlog + ToDo + Dev + Test + Done
Throughput: The amount of work completed per unit of time. This metric measures the team’s capacity and helps forecast future work.
Example: If a team completes 10 tasks in a two-week sprint, their throughput is 5 tasks per week.
SLE(Service Level Expectation) : Based on Cycle time scatter plot percentile lines which forecast how long it will take to complete a task
7. Indicators
Lagging Indicators provide data on past performance, helping teams identify issues and make improvements.
Cycle Time
Lead Time
Throughput
SLE
Leading Indicators offer predictive insights to help adjust the process proactively.
WIP (Working In Progress):
WIA (Work Item Age):
These indicators help the team balance workload and improve predictability in future sprints.
8. Little’s Law
Little’s Law is a formula used to estimate the efficiency of a system based on WIP, arrival rate, and throughput. In this context, Little’s Law applies to the average cycle time and items in the queue.
Average Cycle Time = Average WIP / Average Throughput
Average Items in Queue = Average Arrival Rate × Average Wait Time
By understanding these metrics, the team can make informed decisions to optimize their workflow.
9. MVP, MBI, MMR, and MRF
MVP(Minimum Viable Product) : The simplest version of the product with enough features to meet the needs of early users.
MBI(Minimum Business Increment) : A small enhancement that adds business value.
MMR(Minimum Marketable Release) : A release with enough value for the market.
MRF(Minimum Releasable Feature) : A feature ready to be deployed independently.
Example: For a new app, the MVP might include basic login and profile features. The MBI could be a notification feature that enhances user engagement, while the MMR could be a combination of profile, notifications, and dashboard features that make the app marketable. An MRF could be any one of these features ready for deployment.
Conclusion
Scrum with Kanban combines the structure of Scrum with the flow-based approach of Kanban, allowing teams to balance agility with predictability. By understanding these components—product backlogs, sprint backlogs, WIP limits, Kanban columns, key metrics, indicators, and Little’s Law—teams can improve their project management practices to deliver high-quality products efficiently.
This hybrid approach not only improves task visibility but also ensures a steady pace of delivery, making it a powerful strategy for managing complex projects in an agile environment.
Comentarios