Product Review for Distributed Retrospectives

On a monthly basis, I see at least one distributed retrospective. Sure, I would prefer to do it onsite with participants, on a wall with sticky notes, but that's not always an option. So, what can we do about it? Not having the retrospective is not an option. Instead, I want to find a tool that has a low level of friction, is purpose built, and reasonably priced.  Sounds like it's time for a product review! Over the last few years, I've used several products for distributed retrospectives. Each of them sucked in their own special way. So, I thought about testing Retrium. My first thoughts are I like it!

Currently, they have Five major techniques (4L's, Mad-Sad-Glad, Start-Stop-Continue, Lean Coffee, and Went Well, Didn't Go Well) customized for the distributed experience. With that, I focused my attention on the  "Start, Stop, Continue" technique.

Steps I used for the product review:

Step One: Choose a retrospective format. I picked Start, Stop, Continue.

Step Two: To start the retrospective the facilitator should explain how the technique works. He or she should then tell the team the timebox for the retrospective (30-60 minutes, depending on the size of the team).  In Retrium, you can set a timebox time for each step or the overall retrospective.  I like to set a timer for each step.

Step Three: Ideation. The facilitator should tell participants the timebox for this phase (10-15 minutes should be enough). Participants will then start entering ideas on the board, under the respective heading (Start, Stop, Continue).  As the participants enter ideas, the text will not be visible to other participants (until the grouping phase). I like this features, as keeping ideas private will help ensure participants aren't biased by each other's ideas. When the timebox expires, we move onto the grouping phase.  If people are full of ideas, the facilitator can extend the timebox timer.

Step Four: Grouping. The facilitator then chooses to advance to the idea grouping phase. I'd recommend the facilitator inform the participants that once you move on to the Group phase, you will not be able to return to the previous phase.  Since ideas will likely be related (or even identical), participants should group items into logical themes. Participants can label the logical groups on the screen.

Step Five: Dot Voting. The facilitator then chooses to advance to the voting phase. Again, I'd recommend the facilitator inform the participants that once you move on to the Voting phase, you will not be able to return to the previous phase.  As noted earlier, each one of these phases can be timeboxed with a timer feature located on the screen. In my retrospective, participants had 5 votes they could cast against the groups.  After voting is complete or the timer expires, the facilitator advances the retrospective to the Discussion phase.

Step Six:Discussion.  This is where I believe you are going to get the most benefits from this product. In the discussion phase, only one idea group at a time will be displayed. Here, you will create action items. When you're ready, choose the next topic (group). Add more action items to your Action Plan.  You can then choose to review the action plan or end the retrospective.  This is by far the step most retrospectives fail at. No action plan is easily maintained and worked.

Retrospective History and Action Plan: Now that the retrospective is over, you can go back and look at previous retrospectives and more importantly, have an ongoing action plan of improvement.

So, is Retrium worth the cost?  At the time of this blog post, 1 team room was $49 a month.

You'll get the following:

• Access to all retrospective techniques
• Run an unlimited number of retrospectives
• Invite an unlimited number of users
• Create and track action plans
• View your retrospective history

Is it worth it? I recommend you check out this ROI calculator and dynamically calculate your return on the investment. If you can save your team just 30 minutes a month, through improvements, the product pays for itself.

I would definitely recommend this product!

Full disclosure: I have no financial relationship with Retrium. However, I do know a few of the people there.

https://cdn2.hubspot.net/hubfs/1892587/Retrium_feb2017/images/tour.mp4?t=1518454818997

Cheat Sheet for Backlog Refinement

Backlog Refinement Meeting

What is it?

The purpose of backlog refinement (grooming) is to make improvements to the product backlog.  Though there is no official ceremony detailed in the Scrum Guide, the activity of refining the Backlog is.

Who does it?

Backlog Refinement is a collaborative effort involving:

• (Optional) facilitator – (like a ScrumMaster) keeps the session moving toward its intended goal

• (Optional) representative(s) from the Management Team – clarify the high level priorities

• (Mandatory) representative(s) from the Product Owner Team – clarify the details of the product backlog items

• (Mandatory) representatives from the Agile Delivery Team – define the work and effort necessary to fulfill the completion of agreed upon product backlog items. It is recommended to have at least one developer and one tester when refining the backlog, to ensure alternate viewpoints of the system are present.

When is it?

Before development of a user story in the current sprint (iteration), generally sometime during the previous 1 or 2 sprints, the team sits down to discuss the upcoming work. Do not wait too late to add details, because the delay will slow the team down. Do not refine your stories too far in advance, because the details might get stale. Depending on the delivery rate of your teams, you should be meeting once or twice a week to review the backlog.

Before You Begin

We need to ensure:

• The product backlog is top-ordered to reflect the greatest needs of Management Team and the Product Owner Team

• Candidates for grooming include stories identified as not ready to complete within the next sprint or will require multiple days of research

• Epics, features or other items on the Management Team roadmap are reviewed periodically

The Backlog

The product backlog can address anything deemed valuable by the Product Owner Team. For the purpose of sprint planning, when using Scrum as the delivery framework, product backlog items must be small enough to be completed and accepted during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner team.

Estimate

Backlog items must be completed in a single sprint or split into multiple user stories. While refining, give stories an initial estimate to see if they are small enough. If not, split them. The best way to split product backlog items is by value and not by process.

Acceptance Criteria

All stories require acceptance criteria. Without it, you can not define the boundaries of a user story and confirm when a story is done and working as intended. Ensure acceptance criteria is testable.   This is what your testers should be writing tests against.

Rewrite Written Stories

Ensure the user story format is consistent, INVEST criteria is being met, and is written from a business not technical perspective.  Know who the customer is. It may not be an end user. Rather, the story may be for something like a service, to be consumed by another team.

Image Credit: Pictofigo

Originally Posted at LeadingAgile

Simple Cheat Sheet to Sprint Planning Meeting

WHAT IS SPRINT PLANNING?

Sprint planning is a timeboxed working session that lasts roughly 1 hour for every week of a sprint.  In sprint planning, the entire team agrees to complete a set of product backlog items.  This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint.

WHO DOES IT?

Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment.

HOW DO WE PREPARE?

Ensure all sprint candidates meet the team’s definition of ready.  In the days and weeks leading up to sprint planning, the Product Owner identify the items with the greatest value and works towards getting them to a ready state.

• Assign a relative story point value
• Remove dependencies
• Create testable examples
• Define acceptance criteria
• Meets INVEST criteria

WHAT IS THE BACKLOG?

The product backlog can address just about anything, to include new functionality, bugs, and risks. Product backlog items (PBI’s) must be small enough to complete during a sprint and should be small enough to complete within a few days. All stories must be verified that they are implemented to the satisfaction of the Product Owner. 

ENSURE RIGHT SIZING BACKLOG ITEMS

Based on historical data of the team, first determine if product backlog items are too large to complete in a sprint.  In these cases, do not consider these stories as valid sprint backlog candidates. Rather, in order to consider for sprint planning, split the stories into smaller pieces. Additionally, each story must be able to stand on its own as a vertical slice.  Therefore, stories should not be incomplete or process-based as a horizontal slice.

CALCULATING A COMMITMENT

To calculate a commitment, mature teams may use a combination of both team availability and velocity.  However, new teams may not know their velocity or they may not be stable enough to use velocity as a basis for sprint planning.  In these cases, new teams may need to make forecasts based solely on the their capacity.

DETERMINING VELOCITY

First of all, as velocity is unique to every team, never use another team’s velocity to plan your sprint.  Derive team velocity by summing the story point estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams will begin to focus less on utilization and consequently more on throughput.

DETERMINING CAPACITY

For teams without a stable velocity, each team member should provide three simple measures to determine capacity.  First, what are the number of ideal hours in their work day?  Second, how many days in the sprint will that person be available?  Third, what percentage of time will that person dedicate to this team?

THE PLANNING STEPS

1. Remind the team of the big picture or goal
2. Discuss any new information that may impact the plan
3. Present the velocity to be used for this release
4. Confirm team capacity
5. Confirm any currently known issues and concerns and record as appropriate
6. Review the definition of DONE and make any appropriate updates based on technology, skill, or team member changes since the last sprint
7. Present proposed product backlog items to consider for the sprint backlog
8. Determine the needs, sign up for work, and estimate the work owned
9. Product Owner answers clarifying questions and elaborates acceptance criteria
10. Confirm any new issues and concerns raised during meeting and record
11. Confirm any assumptions or dependencies discovered during planning and record
12. ScrumMaster calls for a group consensus on the plan
13. Team and Product Owner signal if this is the best plan they can make given what they know right now
14. Get back to work

// If your team is new to Scrum, download a copy of the Sprint Planning Cheat Sheet //

Drawings by Pictofigo

The Critical Path Week Ending February 28

Due to working crazy off hours in preparation for my v1.0 launch, I not only forgot to do a week in review on the 20th, I also missed meeting my writing commitment on the 24th and 25th.  Whatever the excuses, I was feeling a little burned out.  I have to remember this is a marathon and not a sprint.  Writing a daily blog takes a lot of discipline.  Though I have so much to say, it can escape me if I don't get the idea captured quickly.  Wow, it's hard to believe it's almost March.  At least there should be viewer posts about snow removal.

2/26/2010

Putting Things In Perspective

I had mild chest and shoulder pains this morning. I am in the ER waiting to see the doctor. I’ll let you know the outcome and my status shortly...

2/23/2010

Satisfying Needed Scope Versus Wants

There are many templates and means to ensure your project meets the requirements.  But I can’t stress enough how important it is to ensure you’re working to satisfy the requirements (or scope) first...

2/22/2010

The Hateful Cycle of Apathy Hits a Nerve

Have you ever stuck your neck out and get no support?  Did the trust among that team start to break down? I’ve seen it happen first hand and Geoff Crane wrote an awesome post over at Papercut Edge about it...

2/21/2010

How To Prevent Your Project From Hemorrhaging

This post is in response to a post written by Jennifer Bedell on the PMStudent blog about goldplating. Goldplating is very common in application development and can be very expensive...

2/20/2010

How Owners Managers and Leaders Differ

I was asked a very interesting question today, requiring me to stop and think. How do I believe being an entrepreneur and a business owner differ? It’s a very good question because...

2/19/2010

What You Need Is Some Kaizen

While sitting in a governance meeting the other day, I heard how (before I joined the team) a vendor brought in some high paid six sigma black belts to...

2/18/2010

How to Thank a Managed Camel

I was informed I am the winner of the very first Freedom of Speech February (FOSF) giveaway from How to Manage a Camel.  My comments last week on a blog post by Gary Holmes earned me a free copy of the Method123 Project Management Methodology (MPMM™) Professional from their partners at Method123...

2/17/2010

Creeping Ever So Closer To Closure

As my startup project is creeping ever so closer to its closure and the actual launch of the product happens, I’m feverishly completing activities late into the night.  It’s not easy working crazy hours to get this done.  My family goes to bed, I drink a pot of coffee, and get to work...

2/16/2010

Interesting PMI Perspective On Claiming PDUs

...Based on the telephone conversation I had, if you’ve worked as a PM for at least 6 months, you can claim 5 PDUs.  Otherwise, if you are able to say you spend more than 1,500 hours per calendar year in that roll, you also qualify to claim the 5 PDUs...

2/15/2010

Getting Exactly What You Want

I just wrapped up a week long logo design project at 99Designs, with an intellectual property transfer agreement.  Flash back to August 2009, when I was watching Episode 13 of This Week in Startups...

How Do You Know Your Metrics Are Worth It

GQM Paradigm

So you want to create some metrics.  More importantly, someone has told you that you need to create some metrics.  How do you know if you're just making work for yourself or if you're just putting a spin on the same old data?

Ask yourself what the goals of your project are.

In trying to determine what to measure in order to achieve those goals, I recommend using a Goal-Question-Metric (GQM) paradigm. It can actually be applied to all life-cycle products, processes, and resources. I've been using this process for a few years and it really helps me creat a quality metric.  The GQM paradigm is based on the theory that all measurement should be [1]goal-oriented i.e., there has to be some rationale and need for collecting measurements, rather than collecting for the sake of collecting. Each metric collected is stated in terms of the major goals of the project or program. [2]Questions are then derived from the goals and help to refine, articulate, and determine if the goals can be achieved. [3]The metrics or measurements that are collected are then used to answer the questions in a quantifiable manner.

Here is an example of the GQM in action:

Goal (use this 4-step process to shape a goal)

[1] Purpose [2] Issue [3] Object (process) [4] Viewpoint

Goal 1

[1] Purpose [2] Issue [3] Object (process) [4] Viewpoint

Maintain a maximum level of customer satisfaction from the Help Desk user’s viewpoint

Question 1

What is the current help desk ticket trend?

Metrics 1 Metrics 2 Metrics 3 Metrics 4

Number of help desk tickets closed Number of new help desk tickets % tickets outside of the upper limit

Subjective rating of customer satisfaction

Metrics 5

Number of new help desk tickets open

Question 2

Is the help desk satisfaction improving or diminishing?

Metrics 6 Metrics 7 Metrics 8 Metrics 9

Number of help desk calls abandoned Number of help desk calls answered Number of help desk calls sent to voicemail

Subjective rating of customer satisfaction

As the great Lord Kelvin once said, "If you can not measure it, you can not improve it."

Image based on Basili, Caldiera, and Rombach "The Goal Question Metric Approach", 1990

Understanding Agile Scrum and common terms

I've been in a few meetings this last week where people were mentioning Scrum terms but didn't know what they were. It's not their fault. The person introducing the terms into the project vocabulary should have provided an explanation before referencing them.

For those of you new to Agile Scrum, here are a few basics:

What is Agile Scrum? There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the lifecycle of the project.  Agile methods choose to do things in small increments with minimal planning, rather than long-term detailed planning.  There is a heavy emphasis on face-to-face communication over written communication.

Agile Scrum is not ideal for every project.  If the project has high criticality, is using junior developers, has clearly established requirements that do not change often, employs a large number of developers, you should think twice about using it as your method of choice.

I've seen it work very well with small (5-9 member) teams, where all the stakeholder knew they wanted "something" within a short period of time.  They did not know specifically what it was nor how to get from start to finish.  We used a lot of wireframes and prototypes to get us in the ballpark, until we could lock down clear functional and design requirements.

I think it's important for people to understand key terms in Agile Scrum as they relate to other project management methodologies.

Roles

Product Owner The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.  This owner could be a project manager, director...  Whatever their title, they must have the authority to make decisions on behalf of the project.

ScrumMaster The person responsible for the Scrum process, making sure it is used correctly and maximizes its benefits.  This is NOT a project manager.  This person is a facilitator.  They are merely there as a communications bridge and to offer motivation or remove impediments.

Team A cross-functional group of people responsible for managing itself to develop the product.  This is a small team (5-9) consisting of at least one person from each area (BA, QA, Risk, CM, Software Engineering...)  This team traditionally sits in the same room or area.

Scrum Team Product Owner, ScrumMaster and Team.  Everyone directly involved in the project, with the exception of users, stakeholders, and managers.

Artifacts

Sprint burn down chart Daily progress for a Sprint over the sprint's duration.  This chart can replace a Gantt chart in illustration of progress.

Product backlog A prioritized list of high level deliverables assigned to teams.  This list is similar to milestone deliveries you'd find in a Work Breakdown Structure.  These deliverables will still need to be decomposed (in the sprint backlog).

Sprint backlog A list of tasks to be completed during the sprint and assigned to individuals.  These are the actual decomposed items from the product backlog.  This list must be agreed to by the entire team prior to the sprint actually beginning.  If there is a change in the scope of the sprint backlog during a sprint, the sprint must be immediately stopped and scope redefined.

Other

Sprint A time period (typically between 2 weeks and 1 month) in which development occurs on a set of backlog items that the Team has committed to.  Sprint time periods are established to provide enough time to deliver something, get feedback, and begin another iteration.

Product An output requested by the customer.  It is a completed document, process, web page, database...  Regardless of what it is, the customer believes that it has value.

Other terms to be listed in a later post: Sashimi, timebox, daily scrum, chickens, pigs, retrospective, user stories...