An understanding of Scaled Agile Framework

SaFe has been designed by Dean Leffingwell and his team. The purpose of SaFe is to scale the agile value from a high performing Scrum, XP and Kanban practicing team to a system and an enterprise level in an effective synchronized way.

Portfolio:

Enterprise: Enterprise represents business having portfolios driven by strategic themes as business driver.

Portfolio Management: Portfolio management owns the responsibility of strategy, program management and governance of a specific portfolio driven by decentralized decision making, continuous value flow, epic and rolling wave planning.

Epic owner: Epic owner is responsible for a portfolio level epic starting from its business case stage to approval to value stream implementation. Epic owner collaborates with multiple stakeholders.

Enterprise Architect: Enterprise architect collaborates with business stakeholders and solution architects to drive a holistic technology implementation across the portfolio value stream.

Kanban & Backlog: Portfolio management kanban addresses the flow of epic that affects value streams & agile release trains. Portfolio backlog is the highest level backlog in a portfolio.

Epic & Enablers: Epic holds the economic value of enterprise. Enablers are the technical initiative supporting business value creation at portfolio level.

Budget & Value Streams: Budget is the approved operational cost in terms of CAPEX & OPEX. Value streams are long lived systems delivering continuous value flow to customer of the enterprise.

Program:

PI Planning: Program increment planning is a 2 days release planning meeting at program level attended by agile teams, product management, architects, system team and other stakeholder. PI planning delivers a program level backlog.

ART & RTE: Agile release train is the team of agile teams that plans, commits and executes together. Release train engineer is the scrum master of the agile release train.

Business owner & Product Management: Business owners are responsible for ROI of the value delivered by a release train. Product management creates program vision and it is responsible for managing a program level backlog.

Architecture Runway: Architecture runway is a planned architecture initiative that enhances solution design, performance, cross team design and implementation. It supports emergent design of the agile team.

DevOps, Release Management, Shared Services, System Team, User Experience: These are the essential support systems enabling agile release train to deliver continuous flow of values.

Backlog, PI Objective & System Demo: Program backlog is upcoming feature and enablers. PI objectives are summarized goal that an agile release train intends to achieve. System demo is the integrated & aggregated view of the new features that an agile release train has built.

Feature & Enablers: Feature is the required system functional definition which delivers benefit. Enablers are technical initiative to support the development business initiatives.

Release any time: Release multiple times during an ART flow depending on development & business context.

Iteration:

Agile Team, Product owner, Scrum Master: Product owner is the owner of sprint backlog collaborates with program product manager and agile team. Scrum master facilitates the agile team and coordinates with other team of the agile train. Agile team is a self – managed team which turns the committed backlog into shippable value for the customer or works on a technical initiative.

XP Scrum & Kanban: XP scrum is a 2-3 week scrum iteration. Team kanban facilitates the agile team in delivering a flow of values through a workflow visualization.

Backlog & PI Objectives: Backlog is the team level prioritized backlog. PI objective is a team level business and technical goal summary.

Iteration planning, execution, demo and retrospective: Iteration planning is the sprint planning where team commits the backlog for an iteration and decomposes the committed backlog into sequenced tasks. Iteration execution is the execution of the committed task using daily scrum and Kanban board. Demo is the team level demo and retrospective is the team retrospective on the processes used in iteration.

Built-in quality: Built -in quality is an ongoing commitment & training on innovative lean-agile methods.

A good User Story

A software development requirement for a customer is a product value he/she has asked for. A development team views the same software requirement as work needed to deliver the product value to the customer.

User story in software development addresses the mis-communication between those who uses (user) the software and those who build (developers) it about what (value) the user wants.

3 C’s of User Story

Card - A physical representation of what a user wants in few simple plane statements.

Conversation – Details of story emerges when the developers talk with product owner and customer/customer proxies about who, what & why of the user story.

Confirmation - Objective of story identified after conversation in terms of resolved & agreed acceptance criteria.

INVEST in User Story

Independent

While conceptualizing an independent user story we should think of breaking the story into smaller vertical layers keeping the required development work in mind. This helps in prioritizing the user story in backlog queue. A dependent valuable user story can’t be implemented without implementing lesser valuable stories.

Example:

1. In a report screen, report download feature in excel and pdf should be created as two independent user stories – one for excel report and one for pdf report.

2. User validation and forgot password features in a login screen can be created as two independent user stories.

Negotiable

A user story is not a requirement. It leads to a requirement through a collaborative conversation between development team and product owner and, customer or customer proxies. Negotiation evolves the customer’s need.

Example:

1. “ I want to search an item” of user story will lead to - “I want to search an item by typing first 3 character of the item name” or - “I want to search an item by typing any 3 character of the item name” after a collaborative conversation.

2. “I want to print the letter” of user story will lead to - “I want to print the letter in a blank A4 paper” or - “I want to print the letter in a pre-printed A4 size letterhead” after a collaborative conversation.

Valuable

A user story should be of value to the user, otherwise, these is no reason for the user story to have a place in a backlog and development team to work on the user story. Value also includes something called “non-functional requirements”.

Example:

1. “As a admin user I want to create other users so that I’ll not be dependent on application support team” has a value for the user of creating login ID's independently.

2. “I want to pay by credit card” part of user story has a value of transaction to be secured as per the required regulation.

Estimable

We can’t size the user story without estimating it. If we can’t size it, development team can’t commit the story into a time-boxed sprint. Sometimes, we face an issue in estimating a user story due to its big size. The user story should be broken into smaller stories. Lack of domain & technical knowledge are the other main reasons which hinder a user story estimation. We should research in the respective areas till we are able estimate the user story.

Example:

1. “I want to purchase a product item by paying online” should be broken down into “I want to purchase a product item by paying online using net banking”, “I want to purchase a product item by paying online using credit card” and “I want to purchase a product item by paying online using COD(cash on delivery)”

2. “I want my website to be compatible with all types of mobile devices” requires a technical research spike if development team has not done this kind of the work earlier.

Small

A user story should be small enough to be delivered in one sprint depending on the size of the sprint. “Delivered” means the story gets the “done” state. Team’s capability, technology involved and methodology being used play significant role in deciding how small a story should be.

Example:

1. “I want to use touch id identification in the system” needs to be broken down into multiple user stories depending on the new functionality impact.

2. “I want to use new optional rule to submit the custom clearance application digitally” needs to be broken into multiple user stories.

Testable

Each user story must be testable in order to get it done. Testable acceptance criteria are the key aspect of making a use story testable.

Example:

1. “The application should open in IOS devices quickly” should be “The application should open in IOS mobile devices with 3G/4G connectivity in 1 second with 95% of probability under a full network strength”.

2. “The batch process of the application should complete in two hour of time between 12:00 AM to 4:00 AM” is a testable user story.

Release Planning - Step by Step

Release planning creates a plan to deliver a product value increment. This plan is called release plan and delivery team commits to the plan. Product owner, scrum master and other stakeholders support the team to achieve plan objective in their respective roles.

Who should attend Release planning meeting?

Release planning meeting should be planned and managed by portfolio management team or the designated scrum master with following invitees.

1. Scrum master – Facilitates the meeting.

2. Business Sponsor – Shares the importance of release.

3. Product owner – Represents business and owner of the product backlog.

4. Delivery team – Shares input on technical feasibility and dependencies.

5. SME & Architect – Provide on-demand expert advice

6. Stakeholders – Impacted by release who help in shaping the release plan.

Input needed

1. A ranked product backlog managed by the product owner

2. Acknowledgement if any new backlog item has been added

3. High level vision and business objective

4. Product feedback, market situation and expected deadline

5. Team’s capability, velocity and availability

6. Meeting rooms, conference bridge, hardware and software tools

7. Flip-chart, whiteboard, marker and post-it

Expected output

1. Release plan and commitment

2. Newly added product backlog item

3. Issues, risks, dependencies, and assumptions to be monitored

4. Suggestions to improve future release planning meetings

Release Planning Meeting checklist

1. Book the calendar of meeting invitees by sending the agenda in advance

2. Plan for the travel if needed

3. Book the meeting room of sufficient size with addition space for breakout sessions

4. Book video conference bridge for distributed teams

5. Arrange laptops, computer and projector

6. Arrange whiteboard, flip-charts, marker, paper, pencil and post-it

Release Planning Meeting Agenda

1. Opening the Meeting -

Scrum Mater welcomes the invitees, states the agenda & purpose of the meeting, and introduces the business sponsor. Business sponsor shares his view on importance of the release.

2. Product vision and roadmap -

Product owner share the product vision with larger picture and roadmap of the product development. Then, he/she explains how this release fits into the larger picture and roadmap reflecting the prioritized product backlog. Any new item added into the product backlog is also shared.

3. Release theme, milestone and number of iterations –

Delivery team leads the review of previous release retrospective and current status of the iterations. All participants decide a release theme & release name collaboratively. Velocity of the team if available is presented otherwise a realist velocity value is assumed. Key milestone delivery deadlines are reviewed. Timeboxes for the release are agreed. All participants come up with 1st draft to release schedule and number of iterations using the roadmap, velocity and key milestone deadlines. Team reviews any new issue & concern has come up.

4. Definition of done, Backlog Item Sizing, Story Mapping –

Team and product owner lead the review of definition of done. Definition of done is updated based change in technology and skill of the team and any other environmental factor. Next, delivery team considers items to be included for the release using the prioritized backlog. SME and product owner clarify the queries of the team around user story and its acceptance criteria which helps them in sizing the backlog item in terms of effort. Team uses different estimation techniques (planning poker is the most popular one) for backlog item sizing. Considered backlog items are mapped to iterations of the release. Larger items are split into multiple iterations. Release schedule and number of iterations are reviewed & updated if required.

5. Dependencies, assumptions and adjustments –

Technical, business, infrastructure and operation dependencies are checked. Assumptions are reviewed. Release impacted stakeholders should recheck their respective dependencies and assumption related impact. Release backlog and release schedule are adjusted accordingly if required.

6. Commit, retrospect and close -

Review of the above two steps are repeated till delivery team and product owner reaches an agreement on release backlog & release schedule. Now, it’s time to commit the release plan. Communication and logistics are planned for the release. All participants of release meeting retrospect the release planning meeting and feedback are recorded. Risk, issues, dependencies and assumptions of the release are recorded. Action plan is prepared and assigned to respective owners. Now, release planning meeting is ready to close.

Input	Steps	Output
Ranked product backlog	Plan Meeting and Logistic	Release Schedule
Vision and Roadmap	Share Vision & Roadmap	Release backlog
Business & architect inputs	Release Theme, Schedule, Iterations	Assumptions
Velocity & availability	Definition of done, story Sizing & Mapping	Dependencies
Meeting rooms	Dependencies, Assumptions, Adjustments	Risks
Tools & stationeries	Commit, Action plan, Retrospect	Feedback

Learn scrum in half an hour

Scrum is a project management methodology guided by 3 principles – transparency, inspection & adaption.

A cross-functional team delivers potentially shippable product increments in an iterative time-boxes called sprints. Inspect & adapt is a major theme in scrum which gives opportunities to improve in the current project itself. The Scrum methodology involves -

A. Scrum Roles

B. Time-boxes

C. Scrum Artifacts

D. Agile Rules

Scrum Roles

1. Scrum Master –

Scrum Master ensures that the team adheres to values, practices and rules of scrum. Scrum Master helps the team to perform it best in an organizational environment by tackling and resolving the impediments on day-to-day basis.

2. Product owner –

Production owner is the only person responsible for managing the product backlog and maintaining its prioritization. The product owner also ensures that product backlog is visible to everyone including the team and other stakeholders.

3. Team –

Team does the work. The team turns the product backlogs into increments of potentially shippable functionality every sprint after sprint.

Time boxes

1. Release Planning –

Release planning answers two question.

I. How a vision can be turned into a winning product in best possible way?

II. How the desired customer satisfaction and ROI can be met or exceed?

Release planning establishes the goal of the release, product backlog, major risks, and the overall feature and functionality that the release will contain. It also establishes the probable delivery date cost if nothing changes.

2. Sprint Planning –

Sprint planning has two parts.

I. What –

Input of this part of meeting is product backlog, the latest increment in the product, the capacity of the team, and past performance of the team. The team decides what functionality should be delivered based in the sprint based of these inputs.

II. How –

Team figures out how to turn the selected product backlog into an incremental “done”.

3. Sprint –

Sprint consists of sprint planning meeting, the development work, sprint review and sprint retrospective. Scrum Master ensures that no change is made that would affect the sprint goal.

Daily Scrum – A 15 minute meeting preferably standup to know –

I. What has been accomplished since last daily scrum meeting?

II. What is the plan for today?

III. What are the impediments?

4. Sprint review –

Sprint review meeting mainly reviews what has been done. Team demonstrates the work that is done and answers the questions. The product owner identifies what has been done and what hasn’t been done. The team discusses what went well and what problems they faced and how did they resolve them. The product owner discusses the product backlog. Sprint review meeting provides valuable input to the subsequent sprint planning meeting.

5. Sprint Retrospective –

Sprint retrospective reviews the last sprint in regards to people, relationship, process and tools like scrum team composition, meeting arrangements, definition of ‘done’, method of communication and processes for turning product backlog items into “done”.

Scrum artifacts

Product backlog, release burndown, sprint backlog and sprint burndown are the scrum artifacts.

1. Product backlog –

The requirement of product that the scrum team is developing are listed in product backlog. Product owner is responsible for creating, maintaining and prioritizing the product backlog.

2. Release burndown –

Release burndown is graphically records the remaining product backlog in terms of user story points or effort across the time.

3. Sprint backlog –

Sprint backlog is the list of the tasks the team commits to complete to turn the product backlog items into a ‘done’ increment. Items in sprint backlog should be decomposed enough to understand the changes in progress in daily scrum.

4. Sprint burndown –

Sprint burndown like release burndown is graphical display of sprint work remaining across the time in a sprint.

Sprint Rules

The 12 agile manifesto principals are the guidelines to make sprint rules.