Checklists are useful reminders for teams to ensure they are considering all of the practices of Lean-Agile.
Starting a Lean-Agile Team Checklist
| Activity |
Description |
| Select the right people |
Select the Business Product Owner. This is a crucial decision.
Select the Application Development Manager and Technology Delivery Manager.
Select the Team Agility Coach.
Select candidates for the team. |
| Select the right project |
Select candidate projects that have a good likelihood for visibility and success. |
| Train the people |
Allow enough time to train the team with the skills they require.
Allow enough time to give developers specialized training:
- Acceptance Test-Driven Development
- Test-Driven Development
- Object-oriented concepts and design patterns
- Automated acceptance testing
|
| Build the physical environment |
Establish and/or build out the physical environment for the team:
- The Lean-Agile team room
- Visual controls, team’s project board
Decide how to handle teams that are not a colocated Lean-Agile team. |
| Tools |
Acquire, build-out, and configure tools and environments for the team:
- Agile life-cycle management tool
- Application life-cycle management tool
- Source control management
- Continuous integration server
- Test frameworks
|
| Plan for assessment |
Develop a plan for assessing maturity of Lean-Agile teams.
Develop a plan for assessing Agile project success (metrics). |
| Transition plan |
Develop a plan for making and managing the transition.
Perform gap analysis
Gather Team Agility Coaches into a community of practice.
If possible, gather Product Managers into a community of practice. |
Business Discovery: Priority Checklist
| Activity |
Description |
| Vision |
Business value vision statement created. |
| Priority |
Business value criteria established.
Chunks of work prioritized relative to other approved items based on Weighted Shortest Job First.
Chunks of work sequenced and approved to continue. |
Business Discovery: Planning Checklist
| Activity |
Description |
| MBI |
MBIs defined.
MBIs prioritized and sequenced based on ROI (relative to other approved items based on Weighted Shortest Job First).
Technical feasibility assessed.
Sized (high level estimate using T-shirt sizing).
Approved to continue. |
| Architecture |
Architectural goals and approach identified, visible.
Dependencies and risks identified, visible. |
| Roles |
Product Management assigned.
Business SMEs identified and assigned.
Product Owner assigned (if possible). |
Business Discovery: Staging Checklist
| Activity |
Description |
| MBI |
MBIs refined with conditions of success. |
| Features |
Features defined and sequenced based on business value based on Weighted Shortest Job First.
Acceptance criteria defined.
Sized (using T-shirt sizing).
Approved to continue.
Sequenced based on ROI. |
| Business Backlog |
Business backlog established. |
Business Discovery: Ready-to-Pull Checklist
| Activity |
Description |
| Business Backlog |
Business backlog defined. |
| Roles |
Product Management available. |
Business Delivery: Iteration 0 Checklist
| Activity |
Description |
| Roles |
ADM and TDM assigned. |
| Team |
Team identified with all of the needed roles: dedicated to the release, funded, and colocated as much as possible.
The team is staffed with all of the needed roles, funded dedicated to the release, and colocated as much as possible
Team has received required training: Lean-Agile software development, Test-Driven Development, Engineering practices |
| Team environment |
Review and define workflow.
Review and define visual board.
Review policies for stories.
Establish logistics for meetings, locations, times, frequency, participants.
Tools for testing, coding, integrating, building are selected and installed.
Established logistics for Daily Stand-Up (time, location, conference call information, website).
Agreed to the ground rules for team life.
Organized (and clean up) the team work space: physical, communication, collaboration.
Set up the team’s project board.
Established the test and build environment. |
| Vision |
Release vision statement is prepared.
The team understands and agrees to the vision, drivers, and expected outcomes for the release. |
| Backlog |
MBIs introduced and reviewed with team.
Refine description, scope, validation, and done criteria.
Identify risks, issues, dependencies, uncertainties, and known impediments. Rank, prioritize, and represent these with stories. |
| Architecture |
Review and define the high level architecture and design.
Architectural goals and approach identified, visible.
Dependencies and risks Identified, visible.
Conceptual design completed. |
| Technology components |
Identify technology components.
Input technology features and/or stories into team backlogs. |
| Feature sequence |
Finalize feature sequence by business value and technical dependencies. |
| Iteration backlog |
Iteration length is set.
Iteration backlog established, populated, and visible.
Stories are assigned to the first few iterations
Input items into appropriate tools.
Team has committed to Iteration 1 plan. |
| Story estimation |
Review and define complexity factors that will be used for relative sizing in story points.
Stories decomposed and right-sized:
- Analysis stories if needed
- User stories for first feature
- Validation criteria for stories are understood
Stories are estimated for first few iterations’ work. |
| Continuous improvement |
Intentionally incorporate lessons learned from previous releases. |
| Testing agreements |
Definition of Done established and documented (unit, integration, acceptance
Testing approach (Unit, Integration, and Acceptance) is committed to and visible. |
| Reporting and metrics |
Book of Work program backlog.
Top-line story points.
Feature burn-up. |
| Artifacts |
Identify product documentation that must be maintained. |
Business Delivery: Iteration Planning Meeting Checklist
| Activity |
Description |
| Vision |
The team understands and agrees to the iteration vision.
All members of the team have a common interpretation of the various terms used in the vision statement. |
| Learning from the past |
For the kind of work we are going to do in this iteration, are there lessons learned or good practices that we incorporate from anyone on this team, on other teams in the organization, or in the literature?
Invite a “Second Set of Eyes” from outside to think through the plan. |
| Story estimation for iteration |
Initial estimate of story points for iteration.
Stories decomposed and right-sized.
Validation criteria for stories are understood.
Stories are estimated for first few iterations’ work. |
| Dependencies and risks |
Dependencies and risks identified as stories.
Impediments identified, posted on team board, assigned. |
| Iteration backlog |
Stories are assigned to the iteration backlog.
Tasks are identified for the stories in the iteration backlog.
Team has committed to iteration plan. |
| Commitments |
Commit to demonstrating the product to key stakeholders at the end of the iteration.
Commit to conducting a retrospection at the end of the iteration.
Commit to conducting After Action Reviews as appropriate during the iteration. |
| Testing agreements |
Definition of Done established and documented (unit, integration, acceptance). |
| Team |
The team is staffed with all of the needed roles, dedicated to the release, and colocated as much as possible.
Team has received required training in Leanban, process, testing, and engineering practices.
Artifacts and deliverables determined (and visible). |
| Team environment |
Tools for testing, coding, integrating, building selected and installed.
Established logistics for Daily Stand-Up (time, location, conference call information, portal, etc.).
Agreed to the ground rules for team life.
Organized (and clean up) the team work space: physical, communication, collaboration.
Set up the team’s project board.
Established the test and build environment. |
Business Delivery: Iteration Execution
| Activity |
Description |
| Input tests / code until tests pass |
Unit test has been completed and documented.
Defects clearly defined, resolved and tested. |
| Run functional tests |
Functional tests have been completed, documented.
Defects clearly defined, resolved, and tested. |
| Run user tests |
User tests have been completed, documented.
Defects clearly defined, resolved, and tested. |
| Update business processes and conduct training |
All impacted business processes have been assessed.
Appropriate changes have been made.
Training has been developed and executed.
Participants have been certified. |
| Business PO / Analyst acceptance |
BPO or analyst has formally validated that the story has been completed and is ready to be promoted to production to support the MBI. |
Business Delivery: Product Demonstration and Review
| Rule |
Description |
| Demonstrate the product as it is |
The demonstration is always done with the product as it is. Avoid using slides or other artificial “demo-ware.” This is possible because the product should always be tested (perfected), usable, and completed by the end of the iteration. |
| It is a conversation |
The demonstration is a conversation between the whole team, the Business Product Owners, and the stakeholders. They collaborate on what has been done, what has not been done or could not be done, and what the current needs are. It is not a presentation. |
| Blame-free environment |
The team has done what it could do and is forthright about what it could not do. It is not a time to assess blame but to describe the facts about what was really done. |
| Everyone is present |
Everyone has a viewpoint to share. Many ears help maximize communication.
As much as possible, avoid redundancy (waste) in meetings. |
Business Delivery: Release Checklist
| Activity |
Description |
| Vision |
Product Manager has prepared the product vision and release vision. |
| Essential stories |
Release planning team has identified the essential stories for the next release. |
| Release plan |
Release planning team has populated releases and prioritized MBIs. |
| Demonstration |
Team demonstrated product to key stakeholders. |
| Retrospection |
Retrospection of the release is planned.
After Action Reviews conducted as appropriate during the release plan. |
Business Delivery: Iteration Implementation
| Activity |
Description |
| Ready for Production |
Code is potentially ready to be released. |
| Promote |
Release has been successfully executed. |
| Value extracted from feature for Business |
Feature has been successfully executed and the Business value has been achieved. |
| Retrospection |
Meeting has been conducted to evaluate success of work effort and ways to improve the process. |
Daily Stand-Up
| Activity |
Description |
| Setup |
Status of stories and tasks have been updated before the Daily Stand-up. |
| Conduct |
Team members showed up on time.
All team members were present.
Team members talked with each other.
Problem-solving and side conversations were kept to a minimum. |
| Team and environment |
Team work space is clean: physical, communication, collaboration.
Team’s project board is up to date. |
| Impediments |
Progress on resolving impediments was reported. |
Daily Stand-up Ground Rules
| Rule |
Description |
| Be consistent |
The Daily Stand-up meets every work day at the same time and in the same place. |
| Show courtesy |
Team members show professional courtesy: show up on time, participate, and listen. |
| Be brief |
The Daily Stand-up typically lasts for 15 minutes. Standing up reinforces brevity.
Extra discussions and problem-solving is conducted after the meeting, when there is more time. |
| Hold a team-wide conversation |
The Daily Stand-up is for the team’s benefit.
Each team member is expected to speak and speaks to the whole team.
The team is not reporting to the Team Agility Coach. The Team Agility Coach is there to help facilitate this conversation but not to lead the session. |
| Answer all three questions |
Each team member answer three questions:
- What have you done since the last meeting?
- What will you do before next meeting?
- What is blocking or slowing you down?
Team members can raise issues and obstacles but not propose solutions. |
| Review impediments |
The Team Agility Coach reviews impediments and status. |
| Swarm |
If you have the skills to help with a task and you do not have something else to do, you should volunteer to join the swarm. |
| Finish work |
The priority is to complete stories that are in-work before starting new stories. |
|
