5 Whys

As I dive deeper into my role as a product owner, I am constantly looking for ways to improve to make things easier for my stake holders, coworkers, and dev team.  One of the things I’ve picked up when writing a user story is to utilize what is called the “5 Whys”. 

To help clarify a description of a story and the value to be delivered, which is then subsequently distilled down to acceptance criteria that a dev codes to and a QA resource tests against, asking “Why” leads the writer of the story to really drill down to what the value is that needs to be delivered.  It helps clarify unknown requirements at times and makes a story concise and easy to understand.

Product Backlog

In a nutshell a product backlog is a prioritized feature list that contains short descriptions of all the functionality desired in that particular feature.  While the PO is in charge of the product backlog not all of the ideas should be flowing from you.  As the PO you’ll be getting ideas from everywhere and it is your responsibility to triage, organize, and prioritize them.  Ideas may come from user feedback, making feature lists around what competitors are doing, or you’ll get feature requests from your own internal teams. 

Users may give ideas to you, but they may not be your customers.  Users may submit ideas via Zendesk tickets, web submission forms, forums like Reddit and others, internal teams/employees or social media.  These submissions may be complaints about the product or processes within it or what they wish they had.  You could build things with word clouds.  

Customers are different from users.  Say your product lies in the educational games arena.  While children are the users the customers end up being the parents buying the product.  

Metrics could also be a way to gather ideas to be added to your product backlog.  This can be any kind of quantitative data that you can get in or from your product.  

It may be important to also list any bugs or any technical work within the backlog.  Prioritizing the list will require consistent communication and interaction with relevant stakeholders so that you are bringing forth the most relevant and valuable features to your product.  

When maintaining a backlog there are many tools you can use, but for those just starting out an easy tool to use is google spreadsheets.  The first column you’d want to add is Date Added.  This will show you when something was added and allow easy sorting for that.  The next column would be Feature Idea Name.  Then after that you’d have the description, i.e. what is overview and desired functionality of this suggested feature. 

If you’re backlog contains a bug there are a few things you’ll want to include when adding it to the backlog.  One you only want one bug report in a story and be sure it has a clear title and proper grammar in the report.  You need simple and repeatable reproduction steps.  Include expected results and observed results.  Screenshots or other pictures of bug in action when user interfaces are involved.  You’ll also want to include the build/version/release where bug was found as not all customers are always on the same release.  

Prioritization criteria will vary by team and company, but it is on the product owner to come to a consensus on how this should look.  Three pretty standard criteria that can be used are impact, urgency, and engineering cost. 

Impact or importance is a way to define in a subjective manner whether or not this particular feature idea would move an important metric.  A high numerical score here using a scale of 1 - 5, with 5 being equal to high importance vs a 1, which would indicate low importance. 

Urgency would be asking the question of how important it is to get this feature out now.  1 being not urgent and 5 being very urgent.  So even though something may be impactful doesn’t necessarily translate into something being urgent.  Maybe users would be saying that something is really affecting their workflow and cutting down on their efficiency and is something that needs to get worked on right away even though this feature might not have the same impact as something else score wise.  

Engineering cost is typically where you’d want to involve someone else, i.e. an engineering manager or a high level developer you’re very close with if you don’t have the technical expertise yourself.  Scoring these stories on a scale of 1 - 5 would have 1 representing something as slow to build (1 month) with 5 being quick to build (1 day). 

Other is another column you could have in your backlog.  There are other potential prioritization criteria to consider outside of the ones already mentioned.  

You’ll want to have a total and status set of columns in your backlog as well.  Total would be a sum of any of the prioritization criteria you gave values to earlier.  Status would detail where the feature is at the moment.  It would include things like whether it needs more definition or to be reviewed even further or to be slotted into a development cycle or sprint.  The target launch date would also be listed in your status column. 

Holding periodic check-ins with relevant stakeholders to prioritize your backlog will ensure you are releasing the most valuable things for them and the company.  

Sprint one of Grandpa Pops Hot Fudge Sauce

As I transition from being a developer on a dev team inside the scrum structure to the product owner and scrum master roles I thought it’d be a fun thought experiment to document my journey of how I’d take a product from idea to development and release.  It is a simple product, my dad’s amazing hot fudge recipe, but one that I think will demonstrate my experience with releasing something in an agile environment.  And who knows maybe you’ll even see it end up on the shelf at your grocery store one day.

That said there are lots of things to do when getting a product off the ground and running and since I’m a scrum team of one I started by logging and creating my own Jira account to manage my product since that is a very common software app that is used today to run agile projects.  From there I made a list of things that need to get done in my very first Sprint Planning meeting and have more or less ordered them by importance and value for the first sprint. 

Then I went ahead and listed out a bunch of things that I know need to be worked on eventually for the product backlog and did a rough ordering of the stories as well, which can be seen here.

Stick around for more updates as I go.

Questions I ask to get up to speed on a new scrum team as a product owner or a scrum master Part 2

Welcome to part two of this series on questions I’d ask during hour one of meeting with the team to get up to speed on what they’re working on and how I could help or see where I know I could help.

1.      What is a typical distribution of story sizes in your sprint backlogs?  

This one tries to figure out, where the commitment sweet spot of the team is, based on the sprint backlog composition. To my observation, teams often work in a more successful way, when a sprint backlog comprises of one or two larger user stories, some medium sized stories and a few small ones.  Clearly actionable stories to start the sprint should always be ready with others that can be moved up to be worked when the first ones are finished.

2.      Are you re-estimating user stories at the end of a sprint? 

If so, under which circumstances are you doing so? That should always be done if a user stories turns out to be way off its original estimation.  The PO should update the stakeholder accordingly so they’re aware of the changes/delays in the project.

3.      What was your velocity of the last three sprints?  

The team should know its velocity, how could it otherwise possibly improve?  If you can’t measure it, you can’t improve it.

4.      How many user stories are typically not finished within a sprint and for what reasons?  

If the team is bullish and picked more user stories than it could probably handled at the beginning of the sprint, so be it—nothing to worry about. Also, there are other incidents that might negatively affect the team’s actual velocity, e.g. sick leave or a critical bug a few days into the sprint. If the team, however, is regularly leaving user stories on the board because estimations were wrong, this is a sign for concern that needs be resolved asap or at the very least the next backlog grooming session.

5.      Are you changing user stories once they become an item of a sprint backlog? 

If so, under what circumstances are you changing the user stories? Making them smaller if the team runs into a problem is certainly not great, but acceptable—if the user story in its reduced form still delivers value. Making it larger after the sprint planning is, however, not acceptable.  If they’re being made larger perhaps breaking it out into two stories would be better.

6.      What are the obstacles the team is facing today?  

If they’re systematic what ideas/tools/additional personnel brought on could be done to remove them?

7.      What are the dependencies on other teams?  

And if there are dependencies, are you waiting for other teams to complete their tasks?  

8.      Define and discuss at least two or three key team goals for the project.  

Some of the answers may seem obvious, i.e. meet our deadline within our budget, but this discussion can often bring out other goals which are not obvious to the team initially. It can help the SM or PO understand team motivations and dynamics.

9.      What are key success factors (KPI’s) to achieve our team goals?  

Defining and discussing key success factors, i.e. minimizing the impact of dependencies, can help identify project-level impediments, risks, and issues which the Scrum Master can begin to address. It also is a good benchmark to review and update as the project progresses.

10.  What do team members hope to achieve with this project?  

I like to get a sense of people’s personal goals for the project in addition to the team goals we will establish collaboratively. Having this information can help keep people motivated over the course of the project. Some people may want to learn new technologies, be part of a high-performance agile team, or have other goals.

11.  What type of work environment do we want to create on this project?  

This question can stimulate good discussion about how team members want to interact with each other to achieve the project goals. Often the discussion centers on trust, communication, collaboration, and respect, but it’s good to make sure there is some agreement (or an acceptance of differences) by the team about what is important.  If there are differences that need mending then a group setting may not be the best place to resolve said differences. 

12.  What can we do as a team to make sure that we support each other to achieve our team goals?  

This question can help the Scrum master understand how team members understand the importance of making commitments as a team rather than as individuals. It can also help the team establish informal agreements about the need for everyone to support each other, to take on roles outside their specialty, and trust their team when they need to ask for help.  Often there are senior or tenured people on a team mixed with newcomers that would love some mentorship and coaching.  Making this a regular goal helps elevate team cohesion, morale, and job satisfaction.

13.  What should we do when we are not achieving our goals or not supporting each other?  

Obviously, this can be addressed in a retrospective, but having the discussion early can be helpful to understand how team members perceive how these situations should be handled. It can help establish the need for open and honest communication built on trust.  Adding an impediment column to your workflow might also help the team feel and see that though work has occurred that just because it is stalled isn’t their fault.  Sometimes defects just need time outside of the team to be resolved and having that column could help in your workflow and planning.

14.  How should we celebrate success for achieving our goals?  

It’s important for the team to visualize and expect success. This discussion can help the team discuss rewards that are meaningful and keep them focused on realizing those rewards.  While monetary rewards can be nice, if you worked any amount of time you know other types of recognition often are more valuable intrinsically to a team and its members.

15.  Who are the domain experts outside of our team?

This is useful to establish who to talk to when a story comes to an impasse, but perhaps an official designee for resolving said impasse hasn’t been identified who could resolve the issue.

Questions I ask to get up to speed on a new scrum team as a product owner or a scrum master Part 1

You’re excited about your new badge, the cheerful HR team, a new company and culture, new products and services that you’re working on, but then you have your first meeting with the team to discuss everything that they’ve been up to their necks in for the last who knows how long and you’ve got to show you can help and fast, but how do you do that?  This will be a multi part series on how I’d navigate my first hour of work in a new role as a Product Owner or Scrum Master.

There will be meetings and greetings to get to know the team and the product, but the following questions are what I would ask during my first sit down with the new team to get to know what it is they’re working on and need help with immediately, with the implementation of scrum, and what long term things we can start to work on.  Certainly the trainer/manager that I’m reporting to might have all this good and covered, but I bring this to you to show what I’d do if there wasn’t structure on a team as it relates to Scrum and how I’d get started if so.

1. How large is your product backlog? This helps to gauge how much work is planned in general, but also how much creativity has gone into the product and how much help the product owner might need.
2. What is the typical age of a user story in the product backlog?  If stories are quite old, i.e. they’ve been in there for 5 or 6 months either due to neglect or its an ongoing story than either it doesn’t have enough detail to close it out in a sprint or it is potentially not relevant anymore to the product, but it has become someone’s baby they aren’t willing to let go of.
3. What is your average lead time from an idea being added to the product backlog to its delivery?  This question helps detail how well agile is actually being implemented.  If it is taking several sprints worth of time to deliver an idea then agile is being ignored in terms of definition of done and estimating correctly.
4. Does your product backlog contain user stories none of the current team members are familiar with?  Maybe those should be re-estimated with the current team members to make sure the estimation is still accurate?  It could be also that the stories are no longer relevant if nobody knows or cares about it.  Every story in a product backlog in agile is technically owned by the entire team and so nobody being familiar with an item is actually a problem of how well everyone is bought into the product vision.
5. How often are you grooming the product backlog?  That should be done at least once a week depending on the state of the project.  For one month sprints 1-2 times a month might be more realistic and effective because not a lot will have changed and need to be renegotiated.
6. On how many user stories are you working in parallel during backlog grooming?  Ideally, a team should not be working on more user stories than it can handle within the next two or three sprints. Otherwise, the risk of allocating resources on user stories that may never make into a sprint backlog becomes too high.
7. How long does the grooming of a typical user story take?  The grooming should not be taking more than one to two sprints and grooming sessions themselves shouldn’t really last more than an hour.
8. How are you creating user stories? (Is it a joint team effort with the PO or is the product owner writing the user stories and the team estimates them?) While it happens and isn’t against the law that a PO writes a story and they may have previous experience as a technical writer it is best that the whole team write the story together to be sure all details are flushed out.
9. Where are you discussing user stories? Are you discussing them only during grooming sessions or the daily standup or also on Slack or via comments on tickets?  Every team has its own habits, and maybe commenting in Workfront, Confluence, Jira, Github or utilizing Slack is an effective means of communication in your organization. As long as this happens before a user story is selected for a sprint backlog, this should be fine. Discussing its essentials afterward is a problem, though.
10. Do you apply a “definition of ready/done” standard to your user stories?  That should indeed be a standard. A volatile velocity can at least partly be attributed to the lack thereof.  While TMI is a thing in social media, rarely is it a problem when crafting a definition of done in your user stories.  If so, of what criteria is your “definition of ready” composed of?  Typical criteria for a “definition of ready” are:
• The description is available
• Acceptance criteria are defined
• The story can be delivered within a sprint
• All UI deliverables are available
• All (probable) dependencies are identified
• Performance criteria are defined
• Tracking criteria are defined
• The story is estimated by the team.
11. Who is writing acceptance criteria and in what format?  It should be the product owner in collaboration with the dev team to create a shared understanding of what needs to be built.
12. How are you estimating the likely effort of a user story?  An estimation poker would be useful.  You can gauge based on past projects and their component parts.  Bringing in domain experts outside of the team will also aid in those pieces that aren’t to be done within the dev team.
13. Are you estimating in man-hours or story points?  Estimating man-hours is better than not estimating at all. However, I prefer user story points, particularly if the application in question is burdened with legacy code and/or technical debt. Predictability and stakeholder communications becomes easier this way as they are featured with a built-in buffer and less micro management on the part of the stakeholder who may be using a stop watch (and a whip) for when estimates go over.
14. How are you practicing the estimation process, if the team shares different opinions?  Preferably, you should observe the team’s estimation process in real life. But in case you have to ask: is it a typical vote-discuss-revote cycle? Or the estimations cover a range, e.g. from 2 to 8?) It is a good way to learn more about the team building state, too.

Scrum Backlog Grooming and why

In purist scrum planning you can plan a sprint, which is a time boxed event of development/work of anywhere from a week to a month, during what is called a Sprint Planning Meeting.  These sprint planning meetings can last up to 8 hours for a one month time box sprint.  That is a long time to plan all the work that is going to be done in the next month.  Not to mention that perhaps things will change during that time that will make some or much of the planning irrelevant as time goes on.  This is possible in situations where consistent work hasn’t already been done with definitions of done completed and estimates by the dev team provided.  Where there has already occurred plenty of work that can be looked back on and estimated accurately going forward you don’t necessarily run the risk of planning that is useless since you already have a good idea of what it is going to take to do the work.

All that said how can you potentially cut down on the amount of time a sprint planning meeting will take?  Answer: Backlog grooming sessions.  Ideally these sessions happen regularly so that the sprint planning meetings are both shorter and more effective.  These sessions are meant to improve the product backlog.  In it you can:

• Write/update user stories
• Decompose a story into several stories that are too big to realistically be done in a time box sprint
• Devs often love as much detail as possible to accomplish a story and so adding more definition or rewriting poorly constructed stories is useful
• With the dev team estimate the backlog items that haven’t already received estimates
• Add acceptance criteria and flush out the definition of done
• Assess deeper (lower down on your product backlog) stories/backlog items and do long term planning with domain experts or just when those items can be done.

Yes it is important to stay focused on the current workload, but don’t get too hung up on not looking beyond the current sprint if needed.  Just because you’re on schedule for the next release doesn’t mean you can’t proactively look to the future and see what additional research, domain experts, or technical hurdles may need to be addressed now before getting to the future.

So good things to do during a grooming session:

Have a stated goal.  Everybody hates meetings that drone on and don’t actually accomplish anything.  Devs especially hate this since they’re up against what they’re already working on and being in a pointless meeting just takes them away from the work they need to get done now.

At the bare minimum hold your grooming session a few days before the sprint planning so people are familiar with the backlog and can hit it hard during the actual planning session.

If you have stakeholders present, limit them to just a handful.  Don’t have 10-20 people in the meeting because they often don’t know the rules of scrum, will make things chaotic, plus people check out when there are too many people in a meeting anyways and input by default is minimized by the sheer size of the group whereas smaller groups can have more people contribute.  Go figure.

Implementing regular backlog grooming meetings helps sprint planning meetings go better and more efficient, familiarizes the team with what is on the product backlog, which then leads the team to committing easier to sprint goals/commitments.