Rapid Release Planning Session & Workshop - Agile Alliance · Rapid Release Planning Session & Workshop V. Lee Henson CST 1. Copyright 2011 Davisbase LLC. V. Lee Henson CST Certified

Rapid Release PlanningSession & WorkshopV. Lee Henson CST

1

Copyright 2011 Davisbase LLC.

V. Lee Henson CST

✤ Certified Scrum Trainer

✤ ADDIE Training Professional

✤ Agile Coach & Trainer

✤ Author of Agile Mentor Newsletter (Published Monthly)

✤ Author of The Definitive Agile Checklist

✤ Inventor of Rapid Release Planning

✤ Former Chairperson of the Scrum Alliance Certification Advisory Board

✤ Information Technology / Psychology Background

2


The Setup:

3


When & Who Are We?:

✤ It is CRITICAL to recognize what has happened so far in the process and where we are now while we are performing these actions:

✤ 1) The corporate and product / project vision has been established. Teams have been exposed to this leadership position.

✤ 2) With the help of executive leadership we have laid out a roadmap outlining what items we anticipate will be delivered in the next few quarters. Teams are exposed to the roadmap to provide technical input.

✤ 3) The product Ownership Group, (PO, BA, FA, TA, Etc.), get together to brainstorm and create cards for candidates to be selected from for the upcoming release.

4


Product Owner:

✤ Responsible for: Creation and maintenance of a stack ranked product backlog.

✤ Gathering of customer, business, and technical requirements and filtering them down to a single product backlog.

✤ Full understanding of the product and the process.

✤ Maintaining upward visibility.

✤ Representation of customer and or sponsor to the end team

5


Agile Analysts: ✤ There are 3 types of analysts to assist the product owner in creation and

maintenance of the product backlog:

✤ 1) Technical Analyst - This analyst understands the way that the current product is built and can assist in determining technological feasibility of future enhancements.

✤ 2) Functional Analyst - This analyst knows exactly how the current product works and understands the direction in which the business hopes to take the future of the product. This analyst is also typically very savvy about how end users typically use the product.

✤ 3) Business Analyst - This analyst has a deep understanding of the customers wants, needs, and desires. They often negotiate with the business to get features into the product that the customer will actually use.

6


The Product Ownership Cloud: ✤ A single product owner would

have a very difficult time meeting the needs of a large organization.

✤ Many organizations introduce the concept of a product ownership cloud.

✤ Chief Product Owners lead the charge by capturing corporate direction and working towards implementation through multiple product owners.

✤ Each product owner works with a team of analysts and market specialists to best define the requirements.

✤ Architects or Principle Developers are often engaged early to determine technological feasibility and framework are in place.

✤ The team becomes involved at the release planning phase.

7


The Product Ownership Cloud

8

CPO

PO PO PO

TA TATABAFA FA BA FA BA

SMT1 T2 T3 TJ


Writing Great User Stories:

9


INVEST - Attributes of a Good Story

10

Independent

Avoid dependencies with other stories

Write stories to establish foundation

Combine stories if possible to deliver in a single iteration

Estimable

Enough detail should be listed to allow the team to estimate

The team will encounter problems estimating if the story is too big, if insufficient information is provided, or if there is a lack of domain knowledge

Negotiable

Stories are not a contract

Too much detail up front gives the impression that more discussion on the story is not necessary

Not every story must be negotiable, constraints may exist that prevent it

Sized Appropriately

Each story should be small enough to be completed in a single iteration

Small detailed stories for the near future

Larger stories are okay if planned further out (Epics)

Valuable

Each story should show value to the Users, Customers, and Stakeholders

Testable

Acceptance criteria stated in customer terms

Automate whenever possible

All team members should demand clear acceptance criteria


The 3 C’s of a Good User Story:

11

✤ 1) The Card - The topic of the backlog item, the high level description of the desired system behavior.

✤ 2) The Conversation - Detailed requirements are only discovered after the backlog item has been pulled into a sprint. This is a dialog between the product owner and the development team.

✤ 3) The Confirmation - Criteria that insures the backlog item was completed to the specifications of the product owner. The customer will evaluate the competed backlog item against the acceptance criteria, and if all tests pass, approve the backlog item by the end of the sprint.


The Card - Part 1

12

Title - The title should be 10 words or less.

Description- As a ________ I would like to ______________________________

so that ______________________________.


Writing a Good User Story Description Template:

13

✤ As a _________________________ I would like to __________________ so that ________________________________.

✤ Example: As a newly Certified ScrumMaster, I would like to log in to the Scrum Alliance so that I can rate my instructor.


Understanding Roles:

✤ Different types of end users may interact with the system differently.

✤ Each role may have many different personas that will exhibit different behaviors and use the same system in a very different way.

✤ Roles help us define broad stroke acceptance criteria that should be applied globally within a system.

14


Understanding Personas

✤ Defining who more specifically will benefit from what you are building helps drive added value.

✤ This helps teams focus on the 20% of the features that are used most of the time.

✤ Using personas also helps the team consume backlog items with much lighter documentation

✤ Most organizations create a handful of most commonly used personas to assist the team in building the product.

15


What About Business Priority?✤ We all know the business has a 3

point ranking scale for priority of backlog items: High, Really High, or Really Really High.

✤ The business needs to use tools to help them understand that not everything can be of the highest priority.

✤ With the understanding that we would not be doing the work if it were not important, which items have the greatest urgency? Can we arrange them into High, Medium, and Low categories?

16

Two websites to assist with priority:http://dotmocracy.org

http://www.innovationgames.com




The Index Card - Part 2

17



so that ______________________________.

Business Priority

H-M-L


Time vs. Relative Complexity

18

✤ Let’s paint the room!

✤ How many hours will it take?

✤ Why all of the different answers?

✤ Have any of you painted before?

✤ Compared to something else you have painted, would it be easier to determine how difficult it would be to paint the room?

✤ Is it easier to reach consensus?


Planning Poker - Does It Work?

19


Let’s Use a T-Shirt Size...

20

✤ Smaller Than XS = a Task.

✤ Extra Small = 1

✤ Small = 2

✤ Medium = 3

✤ Large = 5

✤ Extra Large = 8

✤ Larger than XL = an Epic



21



so that ______________________________.

Business Priority

H-M-L

PO T-Shirt Size

XS - S- M- L - XL


Understanding MoSCoW:

22

✤ MoSCoW = more than a Russian Capital

✤ Must Have

✤ Should Have

✤ Could Have

✤ Would Like

✤ Every iteration should have a mix of the above types of items.

✤ Stake holders LOVE the Would Likes.

✤ The Product Owner drives the product backlog and creates the rank order based heavily on the MoSCoW ratings.



23



so that ______________________________.

Business Priority

H-M-L

PO T-Shirt Size

XS - S- M- L - XL

MoSCoW

M-S-C-W


Create Five Stories

24

✤ Think about what you have learned about user stories Take a few moments to create five Story Cards that look like the ones we have created so far:

✤ 1) Make 5 cards each with a title & description. (Bonus points for using roles & personas in the description.)

✤ 2) Take the 5 cards and give them each a priority. (Remember, this is from the business perspective.)

✤ 3) Take the 5 cards and give them each a MoSCoW rating. (Remember, this is from the customer perspective.)

✤ 4) Next, take the 5 cards and give them a T-Shirt size based on relative complexity & scope.

✤ 5) Finally, take the 5 cards and place them in stack rank order. Be certain to take all 3 corners into consideration when placing them in order.


The Formula

25

✤ Here is the formula for correct placement of stack rank order of your backlog items. Address risk by performing the items with the highest complexity earlier working towards the lower complexity items later in the process:

✤ 1) All Must Have High Priority items should be considered first and foremost.

✤ 2) Be certain to get at least one Would Like in every sprint. Next should be one Would Like High Priority item.

✤ 3) Next should be the Must Have Mediums and Must Have Lows.

✤ 4) The Should’s go next from High to Low Priority.

✤ 5) Finally, place the Could’s from Highest to Lowest Priority.

✤ Note: Dependencies trump priority & moscow rating.

Must Have High Priority

Would Like H-M-L

Must Have Medium Priority

Must Have Low Priority

Should Have H-M-L

Could Have H-M-L

All states are stack ranked from highest to lowest risk unless the velocity of the Sprint does not afford this as an option. Team

velocity always prevails.



26



so that ______________________________.

FA

H-M-L

TA

XS - S- M- L - XL

BA

M-S-C-W


Agile Release Planning:

27


Defining Velocity:

28

✤ How much work can we fit in the release?


Determining Velocity:

✤ What has the team been able to do in the past?

✤ Have they ever worked together?

✤ Do we have historical estimates from a previous similar project?

✤ How much total team time do we have?

✤ How much team time do we predict the first story will take us?

29


What Is a Release?

✤ In order to have a release, you need the following three elements:

✤ 1) A start and end date.

✤ 2) A set of work for the team to complete.

✤ 3) A customer to pass off on final acceptance of the work.

30


Release vs. Sprint Planning

31

Release Planning Iteration Planning

Attendees Team, SMEs and product owner required. Managers/customers optional.

Team, SMEs and product owner required. Managers/customers optional.

Lowest level of work breakdown

User stories Tasks

Estimates Provided in Points, t-shirt sizes, or duration (weeks)

Hours

Output of meeting Release plan (= high level plan for multiple iterations)

Iteration plan (= detailed plan of tasks for one iteration)


The Product Backlog in Release:

✤ Imagine for a moment that the water cooler pictured contained all of the features we could ever want in the product. Each listed in stack ranked order and ready to be placed into a tentative release.

32


The Agile Release:

33

The water line determines our Release Backlog

Given our product backlog and release date, How many cups (iterations) can we fill?


Release Planning Woes:

✤ Teams with different length iterations make release planning a real challenge. The size (length) of the iterations should remain as consistent as possible.

✤ It is truly up to the team to determine what their true velocity really is.

34


Value of Agile Release Planning:

✤ Allows for planning for a series of iterations at a high level, reducing waste in planning detailed tasks for requirements we are uncertain about.

✤ Allows for communication of the entire scope of the release to project teams and stakeholders around a high level plan.

✤ Protects the ability to remain flexible and ‘agile’ by embracing changes in requirements.

✤ Serves as a guide, a baseline, and is expected to be updated based on collaboration and the emerging product.

35


Value of Release Planning Realized:

✤ Understand the need for human and other resources as the macro release level; understand possible decision points for make vs. buy, integration, etc.

✤ Provides the customer and leadership with an idea of how a large project is progressing.

✤ Involves the team in its creation, which means more buy-in, accuracy, and empowerment.

✤ “I know things in a project are going to change, but in my agile projects, I know this information much sooner which allows for good decision making.”

✤ ~ Joe CEO

36


What a Release Plan is Not:

✤ A release plan is not entirely predictive or prescriptive.

✤ A release plan is not planned at the task level.

✤ A release plan is not ‘frozen’, (aka Scope Control)

✤ There is really still no crystal ball to insure 100% accuracy.

37


Rapid Release Planning:

38


Rapid Release Planning Instructions:

39

✤ 1) Print out all of the story cards you hope to be included in the release leaving off the product owner t-shirt size. (After all, we would not want to influence the team.)

✤ 2) Place all of the cards in a large box, bucket, or basket.

✤ 3) Invite all of the teams participating in the release to be part of the rapid release planning session to gather around a large table.

✤ 4) Explain that in a moment you will be dumping out all of the cards. The team will have a pre-allocated time, (based on a scale), to find a card they all agree is small in scope.

✤ 5) Once the team has identified a small benchmark item, explain they will have a set number of minutes to place all of the remaining cards in columns on the wall listed as small, medium, and large relative to the first item and to each other.

✤ 6) If a team member picks up a card they are uncertain about, have them return the card to the table for other team members to review.



40

✤ 7) If an item is smaller than small, make a column for extra small. If the item is larger than large make a column for extra large.

✤ 8) If an item is placed in the wrong column on the wall, feel free to move it. Any card can move except for the initial small benchmark item.

✤ 9) For the final minute / seconds, I command silence and have the team carefully study as many items on the wall as they can in an effort to allow for any final adjustments to be made.

✤ 10) Once the time expires, I excuse the team for an extended lunch and ask the product owners to stick around for a while so we can do a quick comparison.

✤ 11) Any items with no disparity or with only one column of difference in either direction between the product owner and the team is a good enough estimate. The team will get better at estimating as they go and product owner will have a lot fewer items for additional review. The teams estimate in this case is the final one.



41

✤ 12) If there is more than one degree of separation in the t-shirt size between the product owner and the team, this warrants additional discussion regarding that item. In most cases this limits the number of items requiring additional conversation to a much smaller number.

✤ 13) Outliers are marked with both the team size and the PO size and placed in a separate column for additional discussion.

✤ 14) When the team returns, we talk about the outliers for a time-boxed period of five minutes each in an attempt to clarify scope.

✤ 15) The teams estimate stands and we move quickly through the items.

✤ 16) Before we exit the room, the team takes a sheet of round stickies and identifies any backlog items in the release that have an internal or external dependency.

✤ 17) Based on the teams projected velocity, the product owner tentatively places items into future sprints to identify any items that could be considered at risk of not making the release.


Thank You! [email protected] - Twitter @AgileDad - LinkedIn [email protected]

42

mailto:[email protected]




Documents

Rapid Release Planning Session & Workshop - Agile Alliance · Rapid Release Planning Session & Workshop V. Lee Henson CST 1. Copyright 2011 Davisbase LLC. V. Lee Henson CST Certified