Author: Krishna Suryaprasad

Product Backlog:

Backlog should not be confused as a Requirement Document. When applying Scrum, it’s not necessary to start a project with a lengthy, upfront effort to document all requirements.

A backlog is a list of features or technical tasks which the team maintains and which, at a given moment, are known to be necessary and sufficient to complete a project or a release. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers – Progressive Refinement, Emergent and Prioritized.

Product backlog can be considered as the ultimate “to-do” list for the team and Product Owners. It should contain at least three levels

• Product backlog
• Release backlog
• Sprint backlog

Product Backlog can be defined in as structured or as loose as you think is right for your project.  Typically PO or Business Owner finds the Business value at an Epic or a Theme level.

Backlog Hierarchy

User Story – Is an atomic form of a User Need, which can be delivered in a given sprint. It is characterized as a self-contained unit of work which constitutes the building blocks of a Sprint. Typically expressed as “a <type of user> I <want/can/am able to/need to/etc.> so that <some reason>”

Epic – Is a large User Story, which can be broken down into multiple user stories after refinement and can span across multiple Sprint. Epic” is just a label we apply to a large story for example stories for a monthly reporting part of the system are at an Epic Level.

Themes – Is a collection of user stories. A group of stories, one or more, can be from 1 or more Epics. While stories comprising a theme are related, each is independent enough to be delivered separately and still provide some measurable sense of business value.

There are wide verity of estimation techniques available. Some of the prominent examples are

• Counting
• Expert judgment (individual and/or group)
• Decomposition
• Analogy
• Proxy estimation
• Planning poker
• Triangulation
• Wall estimation

And the typical units of measurements are

• Hours
• Days
• Weeks
• Months
• Ideal Days
• T-shirt sizing
• Story Points

Typically, Scrum recommends use of Story Points measurement techniques.

Scrum Estimation  Sizing – Story Points

Story points are a unit of measure for expressing the overall size of a user story, feature or other piece of work – Mike Cohn

Story points tell us how big a story is, relative to others, either in terms of size or complexity. Story points are relative values, not fixed. There is no direct correlation between hours and points. For example, try to use animals instead of, like “dog points” for a relative sizing:, then Chihuahua would suggest a 2 points estimate, Beagle would be 5 points, Labrador would be 8 points and Great Dane 13 points.

We use Fibonacci sequence (1, 2, 3, 5, 8, 13…) as its easy to visualize estimates as a base ten value. Also, it is advisable that each team establish a fixed comparison points for estimation. Teams choose a Story from the backlog that is small and another one that is huge to establish this comparative estimation.

Scrum Estimation Negotiation Practices:

Planning Poker:

• The Scrum Master presents the top item in the product backlog to the team.
• The team discusses the details  related to the story
• The product owner clarifies questions, assumptions, and unknowns—as well as acceptance criteria.
• Each team member privately decides how big this story is relative to a reference story, a series of reference stories, or all of the stories on the product backlog
• At the count of three, everyone shows his or her chosen card simultaneously.

If everyone played the same card, the team can log the estimate and move on to the next story, else have the low bidder and the high bidder both explain their reason estimates then repeat steps 4 and 5.

This is mostly done in a couple of iterations, for example…

Estimator	Round 1	Round 2
Team member 1	3	5
Team member 2	8	5
Team member 3	5	8
Team member 4	2	5

Wall Estimation:

Designed to allow teams to eliminate discussions of 2 versus 3 and 5 versus 8 and instead group things in a purely relative manner along a continuum, at least initially. It also allows stakeholders to give a general prioritization to a large group of stories without getting hung up on whether one story is slightly more important than another. Good for a grooming session, so you can quickly estimate the raw backlog

• Print User Stories into cards
• Join the team and the stakeholders in a room with a big empty wall
• Explain the rules:

• Height determines priorities (top items are more critical)
• Width determines size (left items are smaller)

As with planning poker, we are using relative sizing, but instead of 2 reference stories for comparison, the wall becomes the constant:

Small story? Move to the left. Big story? Move to the right. Important story? Place it high. A story that we can live without for now? Place it low.

   

Ref: https://msdn.microsoft.com/en-us/library/hh765979(v=vs.120).aspx

Retrospective is one of the key aspects of engagement of an Agile Scrum team facilitated by the Scrum Master, attended by implementation team and product owner. These meetings are conducted on the last day of the sprint after demo. Identify start, stop, and continue doing, things to try practices and learnings selecting one or two goals to work on during the next sprint.

Retrospectives is perhaps the most important Scrum meeting which facilitates the principles of evolving an adaptable framework, continuous improvement and inspect and adapt.

It is often observed that Retrospectives can become stale so it’s imperative to keep it engaging and participative and focus on coming up with action items.

Retrospective Guidelines:

The Goal: Create actionable items to improve any aspect of the development process after each sprint.

A Retrospective should:

• Happen after every sprint.
• Be long enough to allow team members to reflect and discuss the previous sprint (45mins – 1 hour.)
• Produce actionable and measurable goals or tasks that can be done by team members.
• Involve all team level developers, PM’s, Product Owners, and anyone else that was involved with the sprint.
• Call out things done well and make a point of continuing to follow the same process that produced those results.

A Retrospective is not:

• A code review
• A blame game (We all should own our mistakes as a team)
• Just another meeting

Retrospective Agenda

Gather Data

• Record a shared set of data
• Consider Objective and subjective data
• Understand facts vs opinions
• The retrospective focus guides what data is relevant for the retrospective

Generate insights

• Move beyond habitual thinking
• Observe patterns
• Understand root causes and influences
• Develop a shared awareness
• Observe / understand systemic effects

Consolidate and prioritize ideas, Decide what to do

• Focus on what the team can accomplish
• Determine one or two actions or experiments
• Don’t necessarily focus on what is ‘most important

Appreciations

“A simple thank you can make a difference; appreciation builds good will, and reminds people that they are valued as human beings, not just as CPUs (Code Producing Units) or FTEs (Full Time Equivalents).”

— Esther Derby

Close

• Recap agreed-upon actions, actors (if needed), and follow up
• Identify ways to improve the next retrospective (retrospect the retrospective)

Methodology – a set of methods, rules, or ideas that are important in a science or art: a particular procedure or set of procedures (Ref: merriam-webster). So, let’s step back a little, Agile is not a mere methodology but a new paradigm a mindset. It is an alternate to orthodox project management practices which prescribed sequential execution like with waterfall. Agile advocates a response mechanism to unpredictable changes through progressive delivery and feedback cycles.

The sequential execution model was inspired by the manufacturing sector which evolved during early industrialization of the world. The approach was phased with predefined gates, moving from one phase to another only after fully completing the current phase. For seven years now software has also been developed in the fashion moving from envisioning, planning, design, development, testing and release to production with clear gate checks at each phase entry & exit. This approach adored several inherent challenges including longer delivery time, rework identification late in the life cycle, money spent on unproductive activities, and lack of effective communication across teams due to compartmentalization.

Agile provides an opportunity to address these limitations through short iterative delivery cycles with endorsed work items at the end of each cycle.  The delivery cycles are iterations of 2-4 weeks duration leading to delivery of potentially shippable product increments. This approach accentuates continuous revisit of every aspect of software development in each of the iteration resulting in enduring course corrections of the projects.

This ‘inspect-and-adapt’ approach exemplify the spirit of Agile resulting in reduced time-to-marked, cost to deliver and improved acceptance. Additionally, the active involvement of users through the delivery cycle creates much better business engagement and customer satisfaction and finally the agile teams are empowered through active involvement, cooperation and collaboration resulting in highly motivated, high performance teams.

Scrum is the most widely used Agile practice due to its simplicity and flexibility. Scrum is characterizes by small cross functional self-managed teams delivering evolving requirements in short durations which are well verified. However, organizations face several challenges while adapting Scrum due to their org structure and practices.

Scrum has three main roles: Product Owner, Team, and Scrum Master. The responsibilities of the traditional project manager role are split up among these three Scrum roles. Scrum has five meetings: Backlog Grooming (aka Backlog Refinement), Sprint Planning, Daily Scrum (aka 15-minute standup), the Sprint Review Meeting, and the Sprint Retrospective Meeting. A more difficult and principled approach to agility in a multi-team organization is called Large Scale Scrum.

Agile life cycle is an iterative and incremental development process comprising four phases to deliver Business
Value in an incremental time boxed cross-discipline iterations. The four phases are

• Inception
• Elaboration
• Construction
• Transition

Detailed descriptions of each phase

Inception:

• Establish a business case for the project – On request from Business Users ((IT Head)
• Identify Program Manager, PO, Architect and TPM (IT Head)
• Establish the project scope and conditions ((IT Head /Program Manager))
• Outline the key requirements that will drive the design tradeoffs (IT Head /Program Manager)
• Outline one or more candidate architectures (Architect/ Program Manager/PO)
• Identify risks and resource needs (IT Head/Program Manager)

Outcome:

• Project Charter – vision, goal, preliminary project schedule and cost estimate
• Solution design
• Identified Product Owner (PO), Solution Architect and Scrum Master (TPM)

Elaboration:

• Address known risk factors (IT Head)
• Capture a healthy majority of system requirements (BRD) – Development of a Product Backlog list (BA’s)
• System Conceptualization and analysis – Establish and validate system architecture (Architect)
• Estimate Cost and Schedule (IT Head/PO/SM)
• For each item on Product Backlog list (PO)
  • Division of items into Sprints (after Prioritizing)
  • Assessment of risk and mitigation strategies
• Conduct a Project Kick-off Workshop with the Scrum Team – Share Project Vision, Goal, Release Plan, Requirements Elaboration,
  Technical Solution Elaboration (PO)
• Conduct Sprint 0 – Grooming, Prioritizing, Sizing, Tasking and Estimating (upcoming 2 to 3 sprints) (Scrum Team)

Outcome:

• Product Backlog (Well defined User Stories)
• Stabilized system architecture – that supports the key system functionality and ensures the right behavior in terms of performance,
  scalability, usability etc
• Release Plan
• Scrum Team

Construction:

• Sprint Planning (Scrum Team)
• User Stories/Product Backlog items are implemented (Coded and Tested) in ‘Sprints’ to result in an executable release of
  the software (Development Team)
• Product backlog Grooming (Scrum Team)
• Other Scrum Ceremonies – Daily Scrum, Review, Retrospective (Scrum Team)
• Capture definite Metrics (Scrum Master/PO)

Outcome:

• Sprint Plan (Commitment based/Capacity based/Velocity based)
• Working Software
• Metrics
• Key Learnings and Continuous Improvement measures

Transition:

• Project Readiness to ‘Go live’ – System deployment to the target users – UAT/Production
• Further Refinements
• Standardization
• E-Learning, User Training, Knowledge Transfers etc

Outcome:

• Release Notes
• Final Build
• Documentation