Scraps from various sources and my own writings on Generative AI, AGI, Digital, Disruption, Agile, Scrum, Kanban, Scaled Agile, XP, TDD, FDD, DevOps, Design Thinking, etc.
Page Hits
Showing posts with label Scrum. Show all posts
Showing posts with label Scrum. Show all posts
Friday, July 05, 2019
Friday, May 10, 2019
Monday, March 18, 2019
Scrum vs. Kanban (Henrik Kniberg)
Scrum and Kanban Summary
=================
Scrum
====
- Split your organization into small, cross functional, self organizing teams.
- Split your work into a list of small, concrete deliverables. Sort the list by priority and estimate the relative effort of each item.
- Split time into short fixed-length iterations (1-4 weeks) with potentially shippable code demonstrated after each iteration.
- Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration.
- Optimize the process by having a retro after each iteration.
Kanban
=====
- Visualize the workflow.
- Split the work into pieces, write each item on a card and put them on a wall.
- Use named columns to illustrate where each item is in the workflow.
- Limit WIP. Assign explicit limits to how many items may be in progress at each workflow state.
- 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, January 17, 2019
Friday, October 26, 2018
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?
- 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.
- Flow of Value / Learnings = Flow of PBI and not the tasks
Subscribe to:
Comments (Atom)
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 ...
- 
Requirements Analysis -- Business requirements document or business requirements specification System Design -- Systems requireme...

 
 



 
