Showing posts with label Scrum. Show all posts
Showing posts with label Scrum. Show all posts

Monday, March 18, 2019

Scrum vs. Kanban (Henrik Kniberg)

Scrum and Kanban Summary
=================

Scrum
====

  1. Split your organization into small, cross functional, self organizing teams.
  2. Split your work into a list of small, concrete deliverables. Sort the list by priority and estimate the relative effort of each item.
  3. Split time into short fixed-length iterations (1-4 weeks) with potentially shippable code demonstrated after each iteration. 
  4. Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration. 
  5. Optimize the process by having a retro after each iteration.

Kanban
=====
  1. Visualize the workflow. 
    1. Split the work into pieces, write each item on a card and put them on a wall. 
    2. Use named columns to illustrate where each item is in the workflow.
  2. Limit WIP. Assign explicit limits to how many items may be in progress at each workflow state.
  3. Measure lead time -- average time to complete one item, sometimes called cycle time. Optimize the process to make lead time as small and predictable as possible.
Scrum vs. Kanban
==========









Wednesday, February 06, 2019

Scrum Impediments

Impediments in Agile are a form of waste. 

  • The scrum master's responsibility is to identify the impediments and help remove. 
  • SM gets into picture when the impediments are beyond the ability of the team.
  • Everyone within the team identifies impediments.

Examples of impediments (leanagiletraining.com):

1. Blockers of user stories
2. People issues
3. Unskilled resources in team
4. Technical issues
5. Lack of knowledge
6. Operational issues
7. Managerial / organizational issues
8. Process issues
9. Disruptions
10. Business / customer issues
11. Etc.

Friday, January 25, 2019

Agile Cereal Box for Product Vision

  • Source - Reqtest.com
  • Product vision describes the product’s goals and customer value. It relates to the problem that the product solves.
  • Vision improves clarity.
  • A good vision can be used to accept or reject requirements. 
  • Product vision box was introduced by Jim Highsmith and can be used for both traditional as well as Agile projects. 
  • Basic idea: create and actual physical box that has to be used to market the product. Common analogy is a Cereal Box.
  • Divide team into two. Multiple boxes. Series of intermediate boxes. 
  • Takes 40 minutes to 1 hour.
  • Front - product name with picture or drawing, slogan, and three to four main selling points. 
  • Back - a more detailed view of the product, listing functionality, requirements, etc.



Tuesday, January 22, 2019

How Scrum Benefits -- Mike Cohn


  • Higher productivity and lower costs
  • Improved employee engagement and job satisfaction
  • Faster time to market
  • Higher quality
  • Improved stakeholder satisfaction
  • What we have been doing no longer works



Thursday, October 04, 2018

Epics, Capabilities, Features, Stories (Another View)


1.1.1.1       Epics

Epics are parcels of work large enough to require analysis and financial approval prior to implementation. Epics are analysed before implementation to identify capabilities and enablers (architectural support). Epics may be combined into a single release or delivered over many releases.
Epics are identified in the project road map and are equivalent to a scope statement. Epics shall provide functional blocks that are sufficiently self-contained so as to provide business improvement in their own right. Business Epics shall provide functionality that aligns with and fully delivers upon one or more Business Requirements. Enabler Epics support the technical considerations for the business epics. Epics have the following states: Funnel, Evaluation, Backlog, Implementation and Done.

1.1.1.2       Capabilities

A Capability is a system service which is equivalent to E2E system Requirement that delivers and traces back to high level stakeholder needs. Capabilities are expressed as the benefit that the system provides the stakeholder. A Capability shall be implemented in a single Project Increment Planning and Retrospective. Capabilities are refined and split into Features. Agile principles discourage large up front design and very detailed requirements. The Capabilities should have detail which can be added in the decomposition into Features and Stories.

1.1.1.3       Features

A Feature is a Subsystem service that contributes to a stakeholder need. It is equivalent to a Subsystem Requirement.

1.1.1.4       Stories

A Story is a short description of a small piece of required functionality. Stories are written by teams to further refine the requirements. They can be implemented by a single team in an increment. They are managed in the team backlogs. Tasks can be identified to implement stories.

Thursday, September 27, 2018

What item of WIP are you limiting in a Scrum with Kanban?


  1. Even if the team is using tasks, WIP limits should primarily be applied to PBI and not tasks. Limiting tasks may be useful, but doesn't replace limiting WIP at PBI level.
  2. Flow of Value / Learnings = Flow of PBI and not the tasks 

If we already have automation, what's the need for Agents?

“Automation” and “agent” sound similar — but they solve very different classes of problems. Automation = Fixed Instruction → Fixed Outcome ...