Archive for category Product management

Getting them on it right: focus, energy, commitment and motivation

“Problems cannot be solved by the same level of thinking that created them.” Albert Einstein.

Less Vicious Circle

I was about to write another one in the scope of “Getting them…” targeted for Product Owners (PO), however thought that before getting them (stories) out of the sprints it is crucial for sprint success how to get them (team members) on it right…

So story going to be about how PO influences team focus and instills feeling of urgency and what happens if he/she’s not…

To understand this we would need to get back to Sprint Planning meeting (SPM). When PO makes final accords, accepts team commitment and sends team out to the sprint it is very important for everyone to stay focused on the Goals PO presented.

If PO jumps in mid-sprint, having unplanned acceptance criteria, special circumstances, etc… this sends a message: goal is void, direction is being changed, things that had been agreed at SPM are not valid anymore.

Scrum is tense way of delivering software. Constructive tension comes from high commitment and builds up high velocity (aka deliver fast lean principle) that is impossible to achieve without addressing limited and fixed number of issues within timebox.

Let’s understand how this works…

Higher velocity is achieved by staying focused on what is most important. As soon as this vector changes, something that had been important yesterday, becomes less important today, or something else emerges focus drifts away.

But velocity is not single thing this impacts…

More drastic effect this has on team morale, since besides team has to conduct context-switch (that has it’s own impact: see another related post here), but also it throws team into “Less” vicious circle that is:

  • Less focus that eats up energy and leads to …
  • Less energy that impacts productivity and leads to …
  • Less commitment that impacts desire to work and leads to…
  • Less motivation that drain attention and lead to …
  • Less focus …
  • Etc …

Understanding this will help PO to plan sprints in the way to avoid de-focus, protect sprints from interference (and team members from de-focus) and minimize impact of unplanned issues.

Of course fire-fights happen, of course they are important, but it makes sense to dive in root causes and build real quality in rather than fight consequences… and eventually turn circle back into “More..” :).

, , , , , , ,

1 Comment

Getting them through: user stories at sprint planning and “estimates temperature”

“If you can not measure it, you can not improve it.” Lord Kelvin

I’d like to continue with “Getting them…” topic (see previous post “Getting them READY: user story life cycle and “Epic Box” principle“). Today we’ll be getting them (stories) through Sprint Planning Meeting (SPM)…

Assuming all stories are INVEST and backlog is prioritized according to value, return-on-investment, risk, etc..

Then it comes to sprint Planning Meeting (SPM) itself…

Here are steps that will help you to get stories through:

1. Be prepared

As Product Owner (PO) you should be quick with decisions as some estimates may be quite “surprising”. I recommend have “plan B” on every story in mind (see Negotiable from INVEST of previous post) as pre-decision what acceptance criteria (AC) it is possible to live without or separate and your idea of estimation prepared.

2. Present it. Sell it!

Start with presenting the goal of the sprint, follow up with  idea behind the story and the problem it solves. Do it in the way to get team buy in. Of course it is your responsibility to decide what is important and what is not, but knowing WHY this is important is vital for correct story implementation and has positive effect on team’s feeling of urgency. Be ready for questions and address them with patience.

3. Applicably question

You should be ready to question estimates if they go beyond your expectation. This is important as empowers “constructive conflict” between parties (team and PO). But please keep in mind that you should be very careful doing this as it should not look like putting a pressure on team.

For instance, instead of asking “Why this is 13 (20, 40, …) story points?” that implies hidden context and will most likely lead to a defensive and broad technical answer you will not benefit from, ask “What makes it 13 for you?” or “How I could split this story so it takes less?” or “What AC make it like that?”, etc.., which is more direct question and assumes no hidden context. Most likely you will be provided with non-technical answer and will be able to judge on “expensive” functionality.

3. “Decode” estimates and implement PO Kaizen 

Estimation process is valuable feedback to PO on stories quality and granularity and it makes sense to use it right. Why? Because as PO you will learn  to improve your  stories and size them the way it will lead to fast, stress-free sprint planning meeting as prerequisite for  successful sprint.

How to “decode” team estimates

Here is my hint: as you know user story point is relative measure of work, but to me estimates have also different meaning  that “signals”, I suggest to be interpreted by PO as follows (assuming that same team estimates continuously using same baseline):

  • 0 USP (orange) – you may have no idea about your product, this functionality is in place;
  • 1/2, 1 USP (yellow) – small (usually cosmetic) improvement. It is OK to group several such improvements in a single story if they contribute to the same WHY clause of story description;
  • 2-3 USP  (light green and green)– small to medium size functionality. All is well 🙂
  • 5 USP (green) – medium size functionality. All is well 🙂
  • 8 USP (dark green) – big size functionality, any way to make it easier or split into smaller? But all is well still:)
  • 13 USP (orange) – do you understand WHY this cannot be smaller/indivisible?
  • 20 USP (dark orange) – you should have very STRONG reason of having such a story. Make it smaller and simplify;
  • 40 USP (red) – no way this will be done during a sprint. Understand what makes it that big and split;
  • 100 USP  (dark red) – damn big amount of work/ambiguous acceptance criteria/big doubts, serious problems, etc;

When turning those signals into color scheme planning poker logically turn into sequence, reflecting “estimate temperature”:

4. Track time

Besides, I recommend to track time spent per user story discussion (use hourglass or timer, or ask your scrum master to facilitate). My observation of sprint planning over 2 years proved that team usually able to estimate ~10 user stories per hour as average (3 teams of ~ 15 people in total). Of course it depends on the size of team and many other factors, but to me if a story takes more than 10 minutes to discuss, PO shall do something with it (question what causes doubts, remove story from planning completely or partially).

5. Ask for feedback

Asking for short feedback at the end of sprint planning also helps to improve. It’s good idea to hand over paper with INVEST acronym reminder where team members place comments on stories and quickly feedback to PO in the last 5 minutes of SPM, referring to particular quality of INVEST and particular story that had not meet this requirement. This is timeboxed to 5 minutes and helps to improve quality of SPMs a lot.

To be continued…

, , , , ,

1 Comment

Getting them READY: user story life cycle and “Epic Box” principle

I’d thinking to cover this topic long ago. This would be the start for the series of posts on PO work to “Get Them…” (user stories) ready, in and out of sprints…

I would like to start with describing what cycle user story goes through before it becomes READY for sprint planning meeting and how PO handles this cycle.

For sure there are many best practices to get stories READY and write proper stories. Instead of focusing on story-writing itself, here I will cover PO workflow to them ready.

So, here are my 5 cents…

Assumption: user stories are part of shaped big wish (called epic), that is part of Agile release/roadmap and takes place on “storymap” that had been presented to development team some time ago.

What does this means?

This would mean that:

  • Value brought by an epic (and future user stories) is clear to everyone;
  • Possible big “underwater” problems it may cause surfaced (reworks, performance, missing data, uncertainty, etc.);
  • High level estimates are given to an epic;
  • Big questions are addressed;

As next step PO prepares epic further, splits into particular stories, sizes each of them and “hones” acceptance criteria (aka satisfaction criteria). To proceed we need to know what does INVEST mean.

What is INVEST?

Things PO should keep in mind when doing story-writing and story-splitting is “INVEST” rule. It stands for:

  • Immediately Actionable – so that team can start working on it immediately;
  • Negotiable – so that can be quickly made smaller/bigger by removing/adding scope of acceptance criteria (AC);
  • Valuable – so that everyone understands what value it brings to an end user;
  • Estimable – so that it can be estimated with user story points or ideal hours;
  • Sized to Fit In – so that estimates fit in established iteration length;
  • Testable – so that has understandable and achievable acceptance criteria;

Splitting an epic

Then it comes to the split itself. I suggest doing the following way:

1. Have a pencil and paper talk  with your PO peer(s) on the epic before splitting:

  • define overall description (As a WHO I want WHAT so that WHY);
  • agree on the way to reach WHAT (draft acceptance criteria, aka AC);
  • write AC down. You will end up having many AC, e.g. 30 or more;

2. Request, get and provide stories with everything that makes them immediately actionable (e.g. designs, data, clarifications, everything that has to do with 3rd parties, etc.);

3. Define story split logic, so that they all can be worked on quite independently and placed in a sequence that satisfy following criteria:

  • upper stories do not require functionality of lower stories (and lower stories do not impede implementation of upper stories);
  • functionality is split logically, trying to keep stories ~same size (remember, best sizing of stories is 3-8 user story points);
  • upper stories allow user to see maximum valued functionality first;

4. Define each story description and split overall AC accordingly. Keep in mind that at this point new stories will pop up (I call them “conjunction stories”).  The rule is easy to understand.

Epic Box Principle: “As soon as you start emptying  virtual box of epic functionality, removing and shaping story after story out of it, you will find out something that is still there and was not your initial plan”.

If your plan was to split epic into 4-5 stories, you may end up with 7-8 or so. That is one of the reasons that explains why usually epic level estimates are smaller than sum of estimates of all corresponding stories.

Important hint: do not hesitate to split as combining is way easier. Splitting is good exercise because enforces to think through value->solution again and discovers potentially hidden problems, functionality etc. Another effect of splitting bigger stories into smaller is reducing doubt (and therefore risks) team will have associated with big story. It turns afterwards into saving user-story-points…
Therefore, it’s way better to have detailed backlog rather then let team estimate their doubt wasting story points on your inability to think through solution and side functionality that may popup during implementation of bigger chunks.
Remember: as PO you are in charge of what team does next and need to have stories prepared accordingly.

5. Peer review all stories with your colleagues after you consider them as READY to see what is missing, question how each AC may be interpreted, best guess on possible estimation;

6. Re-do steps 2-5 until stories are INVEST and  READY for sprint planning meeting (SPM);

To be continued … (“Getting them through sprint planning….”)

, , , , ,

1 Comment

Dynamic Story Board: KANBANizing story map

“Imagination is everything. It is the preview of life’s coming attractions”. Albert Einstein

An interesting thought came to me while thinking on how to bring in dynamics in story map to make it a tool that will help PO both in day-to-day work/tracking and overall release management.

Key benefits that will serve this are:

  • A full picture of upcoming product being built (within scopes of upcoming releases);
  • Transparency about features are being worked on now/coming soon;
  • Highlighting what features are READY and DONE;
To get the complete idea one needs to know the concept of story maps.
Combining this idea with KANBAN flow management framework makes a nice tool for PO:

Dynamic Story Board

So, let me explain what rows of it mean:
  • Done row indicates stories that correspond to the functional areas of the product and are accepted by product owner in sprint review meeting(s), having story definition of DONE met.
  • Areas row indicates key functional areas of the product as any story map has.
  • Wip row indicates work-in-progress, e.g. stories that are part of the running sprint (that team committed upon);
  • Ready row indicates stories that are ready to be presented to team according to definition of ready. PO moves stories in this row only if those compliant with INVEST rule;
  • Pipeline row indicates all the stuff that is planned for the future. As you can see some stories are non-READY here for whatever reasons (not yet completed, or even bigger items (epics) that are not yet prepared for sprint planning and thus cannot be taken by development team);

NOTE: pipeline row can be splitted itself into several rows to indicate scope planned for releases.

This simple board will serve as Kanban-style board turned by 90 degrees CCW. You can always add rows that indicate whatever states your PO team will find beneficial. Such a board can be easily used by PO daily in managing both day-to-day focus on getting READY for upcoming sprint, while keeping an eye on overall priorities and backlog.

Here’s real-live example implemented:

Dynamic StoryMap LIVE

, , , , ,

Leave a comment

Roadmap Planning: “steering” with product map

Roadmap planning is indispensable part of Agile project management that represents second level of 5 levels of agile planning that any team should somehow cover. As a best practice suggests it needs to be done by product owner every ~2-6 months, depending on the intensity of development.

  This exercise makes sure that entire team understands direction, goals and vision of the product team, brings many benefits and speeds things up by creating shared clarity about future and maintains high focus on the “vector” PO gives.

Recently I’ve facilitated Roadmap planning session applying  two techniques: planning poker and story map. For those who want to get details of both techniques I would recommend  nice extract from Mike Cohn’s “Agile Estimating and Planning”: http://planningpoker.com/detail.html and this nice article at Jeff Pathon’s blog: http://www.agileproductdesign.com/blog/the_new_backlog.html.

It was both interesting and challenging, especially since we’ve never try this before. It was great success since resulted in having clear, estimated and planed Roadmap for product fist steps.

Goals:

  • To share product roadmap and vision;
  • To make challenges and risks visible and clear and address them early;
  • To make approximate measurement the minimum required scope of the release of the product;
  • To predict possible release date range / manage product scope in the way to hit deadline;

Background/Preconditions:

  • PO prepared items (user stories and/or themes) written on index cards (one per card);
  • Items were grouped according to the story map (by corresponding key product functional areas);
  • Key area titles were stick to the glass wall at our big conference room;
  • Horizontal line was drawn to separate the first release content over the wall;
  • Scrum team in one room for 2 days;

Process:

  • PO presented key functional areas of the product being built, briefly describing what each area covers;
  • PO started presenting item after item, sticking on the corresponding map column of the wall, given priority he had in mind.
  • Team estimated item presented with planning poker.
  • When estimations were too different we’ve allowed 1 or 2 rounds of re-evaluations. Well, we did not played exact poker, since we were interested in the approximate estimations, so we took averaged estimations  (i.e. majority raised 5USP, some guys 8USP, 6 or 7 is taken as an average, more feeling-based);
  • As soon as a column was complete discussion on required minimum scope of the release content started and PO moves some items below/above “scope line” (also considering estimations and best guessing for ROI).
  • Moving on and on to the next product column and item after item of a story map;

Outcome:

As result of 2 days workshop we’ve manage to:

  • Gain shared clarity about what needs to be done to get product LIVE;
  • Identify biggest project risks and “hairy topics” with poker estimations (those had usually high estimates, more than 20 USP, clearly);
  • Agree on next steps (to start with risky but must-to-have items first);
  • Noticed dependencies among items and moved them up/down in the way to decrease them;
  • Estimate roadmap and predict delivery dates range (we’ve ended up having kind of 500 USP);

Estimations/Approximation:

  • On the level of details where items represent Themes rather than a requirements or stories according to the cone of uncertainty estimations vary from 0.8 to 1.25x factor. On the requirement/story level they also vary from 0.85 to 1.15x. Considering this I took an average  ratio, given the fact that some items were story sized, others were bigger (nice article that illustrates correlation between estimation accuracy and uncertainty from Agile101: http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/).
  • This number together with average team/historical velocity gave an idea of the range required to get product out within agreed scope;


Takeaways
:

  • Roadmap planning is a valuable and must to have regularly exercise;
  • It is both interesting and motivating for team members;
  • PO gains a lot of important insides about product that allows to manage release scope and prioritization to minimize risks and get to live ASAP;
  • Teams are enabled to plan more than  just in time architecture since bigger picture of the product becomes visible;
  • It shall be done outside of a sprint to guarantee 100% clear mind and focus;

P.S.: * many thanks to my CPO, would be impossible without his preparation and buy-in.

, , ,

Leave a comment