SSW Foursquare

Rules to Better Product Owners - 29 Rules

  1. Do you know how to be a good Product Owner?

    The client is generally the Product Owner (PO). They should read the Scrum Guide and watch the Product Owner video to understand their role. It is so important to the success of their project:

    Video: What is a 'Product Owner'? - Scrum Guide (2 min)

    What should I do in order to be a good Product Owner?

    1. Be available for Sprint Reviews, Retrospectives and Sprint Planning meetings (approximately half a day for these 3 meetings, for each 2-week Sprint)
    2. Prioritize the Product Backlog. The important things will be done first, in order to maximize the ROI as the budget will run out one day
    3. Be available (at least remotely) to unblock a developer if they have questions/impediments. A good PO has a feeling of urgency
    4. Ideally, listen in on Daily Scrums. This is optional but means that the PO will have daily insight into the team’s progress.
    5. Understand Product Backlog Items (PBIs) and be able to explain what they want using Acceptance Criteria. This is the main way that developers and POs sync their understanding of what needs to be done.

    Note: It is helpful for developers to distinguish acceptance criteria between what is considered "essential" and what is merely "nice to have," as this can prevent them from investing excessive time in meeting non-essential criteria.

    1. Set a Product Goal (the "why" of the Product)
    2. Agree on a Sprint Goal for each Sprint (the "why" of each Sprint)
    3. Not influence (or anchor) developer estimates with comments like “this one will be easy” and allow the team to come up with converged estimates
    4. Respect the Sprint Goal by understanding the team will only work on things in the Sprint Backlog. Don’t expect other things to be done on top of it. Most things can wait for the next Sprint

    Who should be the Product Owner?

    It’s hard to give guidance on who in the company would make a good PO. The usual candidate is often extremely busy. It should be someone:

    1. With a personal stake in the success of the project
    2. Who is available
    3. With a clear vision of the product
    4. Who has authority with the budget. E.g. they could authorize adding a designer to a Sprint for a couple of days
    5. Who has read the Scrum Guide, watched the Product Owner video, and understands the role

    It’s possible to outsource the role of PO to someone in the development consulting company, but this is not recommended ("don’t put the fox in charge of the chickens").

    “Most dysfunction I see in Scrum teams is caused by a bad Product Owner” Adam Cogan - Professional Scrum Trainer,, during a TechEd session

  2. Agreements - Do you book the next Sprint ahead of time?

    Unless we're currently working on the last Sprint of the development, you should always book the next Sprint as soon as you start work on the current one.

    This is done during the Planning meeting and will ensure the availability of the developers who are up to speed on your project and stop them from being booked onto something else.

    Scheduled Appointment
    Figure: If you have booked the guys in, you will have an appointment like this in your Outlook

  3. Agreements - Do you join the team as a "tester"?

    Testing is a vital part of any development and can be quite time consuming, depending on the complexity of the application.

    As the Product Owner, you are the one with the best knowledge of the desired functionality for the system. You can reduce the project costs by a substantial margin if you are willing to come onsite and help out with testing yourself.

  4. Agreements - Do you know who pays for 'bugs'?

    You WILL discover bugs in any newly developed software. This is perfectly normal. It's important to have a common understanding with your software developers about what to do when they arise.

    'Bugs' are generally a consequence of the development team not knowing every possible scenario when adding error handling. Generally speaking it takes developers just as long to add the error handling before you test it than after you test it. Bugs can also occur when development requirements change on the spot or work is not sufficiently specified.

    For these reasons, fixing such issues is generally billable work on time & material contracts. On fixed-price contracts, bugs are generally fixable within the warranty period at no cost to you.

    What is a bug?

  5. Agreements - Do you provide a Product Owner?

    There are lots of stakeholders in a software project. Users, Marketing, Managers, they all have requirements for the new system but if the spec becomes a free-for-all, it is more likely the project will be steered off-course.

    Select a "Product Owner" - who is the sole person able to make scope decisions and authorize work.

    Remember it's all too tempting to allow the DBA to authorise work without seeking proper authority, so insist that your software consultants follow the standard on getting work approved through a Product Owner.

  6. Agreements - Do you have 1 or 2-week Sprint?

    Depending on how much visibility you need on ongoing costs, you will have to decide whether to use 1 or 2 week development iterations.

    A 1-week Sprint is for small projects (less than 2 months) or if constant visibility into costs is an important factor, as it gives better feedback to the Product Owner.

    Note: This can be at the cost of increased overheads.

    A 2-week Sprint is the most common and allows a reasonable amount of work to be done for each release, while minimising Project Management overheads.

    A 4-week Sprint is a smell.

    It is important to note that as more project management overheads are added, these will have to be paid for.

    "The more you want to see how much you're spending, the more you'll spend".

    • Ulysses Maclaren

    It's important to find the right balance for you.

    Internal Projects

    For internal software development projects, since there is less cost involved in project management overhead, 1 week Sprints are recommended.

    If there has been less than 5 man-days of effort during the Sprint, however, (e.g. due to leave or interruptions), keep adding 1 week to the Sprint until you have at least 5 man days of effort worked.

  7. Agreements - Do you use an experienced Scrum Master (or Project Manager)?

    Some clients think that a Project Manager is just a resource that increases the cost of a project. But a house does not get built if you leave the architect, carpenters, electricians, and plumbers to just work it out between themselves. The house does get built if the foreman is keeping everyone on their toes, making sure they are doing their job.

    Software teams often come with a Project Manager. You can do better than that by getting a Scrum Master.

    It's generally best for the Scrum Master not to be a member of the development team. This way they can stay objective and it creates more of a ceremony when they turn up.

    Tip: If they are trying to be a member of the development team and a Scrum Master, call them a 'Semi Scrum Master" as they often don't do as good a job.

    Here is a common way a project goes with a Scrum Master involved:

    • The Sprint Backlog is approved by the Product Owner (the customer)
    • The development team works on the Sprint Backlog (usually 2 weeks)... The Scrum Master is ensuring the client is kept up-to-date (via the Review, Retro, and Planning meetings) #1
    • The Scrum Master is ensuring the client is kept up-to-date (via the 4 reports)
    • The Account Manager is booking in future Sprints (after the Planning Meeting)
    • The Account Manager invoices (usually every week).

    This is much better than the old waterfall method which goes like this:

    • The specification is approved by the customer
    • The development team is working to the specifications for some months (but can be from anywhere from 2 months to 2 years)
    • The Project Manager is ensuring the client is kept up-to-date (via ad hoc meetings)
    • The Account Manager sends invoices when milestones are met.

    Insist that your Scrum Master (aka Project Manager) maintains a strict project schedule.

    For Scrum Projects: In Scrum projects, the role of a Project Manager is split into three roles: Scrum Master, Product Owner, and the team. Each role is essential.

    For more information go to Scrum Terms and Scrum Roles.

  8. Communication - Do you make sure you are specific in your requirements?

    When you're scoping the work to be completed, ensure you are as accurate as possible in your requirements.

    Be specific

    "I want to keep contact details on my clients"

    Figure: Bad example - Likely to require later clarification

    "I want to record my clients' firstname, surname, mobile phone, email address & Instant Messenger address."

    Figure: Good Example - You'll get exactly what you want. Even better, use screenshots or mock-ups

    One email or Product Backlog Item per task

    The best way for this to work is to break tasks into the smallest possible bite-size pieces and ensure that those pieces are in the project plan explicitly.

    Sometimes software developers miss a related item that you might consider 'blindingly obvious.' For example, you might ask them to fix a combo box on one form in a legacy application. But they mightn't know about the 3 other forms that the same type of combo appears on. So if you also want them fixed, then let them know about them!

    Get approval for UI changes

    Make sure software consultants conduct specifications by creating mock-ups.

  9. Communication - Do you read and manage your emails carefully?

    Email has a bad name in business primarily because people don't treat email correctly. Email can be a vital tool to your company, and your software development project, but it has to be managed. Email should be an accurate record of requests, conversations, and decisions. Emails are legal documents and should be treated with the same care as any other correspondence with clients or employees. Email is also an extremely effective task tracking tool, and requests made by email should be treated with the same seriousness as Project Plans and other directives.

    Software developers send many queries via email, we ask that you pay close attention to your Inbox and respond promptly.

    Insist your software consultants follow the standards to better email

  10. Communication - Do you respond to queries quickly?

    Now we're working, you'll get loads of questions. Most software projects demands close interaction with the Client. As the developers are usually working to tight budgets and schedules, getting quick answers to questions is a must. The Product Owner should be able to answer developer's questions within 4 hours. Otherwise decisions will be delayed and costs increase.

    A good way to fix this problem is to insist your software consultants contact you via Skype or Lync.

  11. Communication - Do you know how to communicate product progress?

    As a Product Owner, you are representing the product's stakeholders on the Scrum Team. You will be a representative of the product to other people in your business, such as your manager. You will often be asked the question "How is your product going?"

    A good way of keeping stakeholders informed of progress is holding monthly meetings.

    Monthly meeting agenda

    To prepare for meetings and maximise the chances of success for your project, ensure you have answers to the following questions:

    1. Value - What features have been delivered recently? Celebrate your successes and demonstrate how your product is adding value to stakeholders. Examples could include:

      • A new login screen with better accessibility for visually impaired users
      • A shortened user registration process
      • Support for a new business process

      Tip: If you record your Sprint meetings, you can ask the stakeholders if they would like to review them.

    2. Development - How has the Roadmap progressed? Explain how the completion of certain PBIs contributed to achieving the aim of the Product Roadmap. For example:

      • Internationalization epic - Added Mandarin translations for an Angular component
      • Subscription epic - Added payment processing

      Tip: Software such as GitHub Projects and Azure DevOps can be used to graphically demonstrate progress.

      github product roadmap
      Figure: Progress for SSW.EagleEye epics in GitHub Projects

      product roadmap
      Figure: Progress for SugarLearning epics in Azure DevOps

    3. Development - What delays or blockers have been encountered while writing the software? Software development is painful and costly. Explain the difficulties that the project has encountered, and detail your plan to overcome those difficulties. For example:

      • The upgrade between Angular versions has been slower than expected. We have booked in an expert to assist the team
      • The new customer registration process was taking longer than expected to implement - the original prediction was 4 effort points, and is now expected to take 16 (and has 14 remaining). Originally it was going to be 3 screens, and is now 5 screens
    4. Operations - How do the product's metrics compare historically? If you have responsibility for the operation of your product, you need to be tracking metrics such as the number of users accessing the system or how many hours they are spending on your site. Provide graphs to demonstrate trends. For example:

      • Have a graph demonstrating how the user count has changed over the last 6 months

      user metrics
      Figure: A graph helps demonstrate trends affecting the Product

    5. Health - What issues have been seen in Production? All errors should be logged, so you should be able to list:

      • Visible errors - errors that impact the User eXperience (UX) negatively
      • Invisible errors e.g. unhandled exceptions, unexpected SQL log messages
      • Performance issues

      All such issues should have plans for investigation or rectification. For example:

      • ✅ DONE - The frontend experienced an increase in errors when adding new users to the system. This was tracked to a bug in how data is being serialized from the backend, and was fixed last Sprint
      • TODO - Since upgrading the database server version, a significant increase of 2 seconds in server response time has been seen. System Administrators are investigating
    6. Planning - What decisions have been made regarding the project? As Product Owner, you will be approving changes to the behaviour of the product and many of these changes will be in development. Explain the decisions that you've made and their rationale. Try to catch misalignments in stakeholder views before your decisions are coded. For example:

      • I have modified the permissions model for the website to allow contributing users access to unpublished articles, as they often request input from each other
      • I approved the mock-ups for the website redesign, as they were cleaner and easier to understand than the current website pages
    7. Vision - Are we still happy with the Product Goal? Circumstances and priorities change - in extreme circumstances, the Goal may need to be changed completely. Work with your stakeholders to ensure that your Product Goal fulfils their requirements. For example:

      • When building a Learning Management System, we noticed that users were heavily using the Markdown functionality. So the Learning Management System was ditched, and the product was pivoted towards creating a Markdown editing system.
    8. Planning - Should the Roadmap be changed to align with the Product Goal? Do we need to add, change or delete any Product Roadmap items to ensure that we are working towards the Product Goal while making efficient use of development resources. For example:

      • When users write new articles, the hardest part is to add links to other articles. Therefore, work should be prioritized to improve how links are created between articles
      • When a new account is created, it is taking 4 minutes to provision. We need to aim to reduce this to 1 minute
    9. Resources - do you have everything you need to complete the updated Product Roadmap? Ensure that you have agreements for staffing, services, extra consultants and additional resources to ensure that the Roadmap can be delivered. For example:

      • To implement the new article search functionality, approval is required to cover the development and the Azure Search Service instance
      • To implement the AI co-writing feature, approval is required to bring in an external expert to advise the team

    Good Example - Roadmap Rodeo for SugarLearning

    Here is a full example of how to record a Roadmap Rodeo in an email.

    Email Template - Record the Roadmap Rodeo

    Use the email template below. Note that this template uses "epics", which are collections of PBIs.

    Figure: Template for Product Status Review email

  12. Triaging - Do you remember that any changes you request will impact on budget and time?

    Often towards the end of a project, you may request extra pieces of functionality ("Can you add a second email address field into the Client Contact form?"), or maybe another report is required. Even in the middle of a project extra work can be requested as project goals move. So long as there isn't a technical or business problem with the request, the work will be scheduled by the developers and done.

    Every new item that is requested increases the total hours and scope of the project and therefore the cost. If the project has a drop-dead date or budget, don't ask for things that will blow these deadlines out. Or, if you want your developers to work to a budget, ask them to let you know what 'can't be done.'

    Insist your software consultants correctly triage additional item requests.

  13. Triaging - Do you understand deadlines often move or scope has to change?

    If you have a tight schedule and deadline for the release, we need you to be clear with your developers right at the beginning about what needs to be done and when. Most developers generally can't guarantee they can work with your deadlines, but they'll be honest up front about when items can be completed.

    Your budget and deadline may mean some items will not get done.

    Sometimes their estimates on items are way too short or too long. It is very hard to be 100% accurate when estimating hours to complete work.

    The best way to keep track is to insist on a weekly release update/debrief.

    For Scrum Projects:

    Deadlines don't move, features do. At your Daily Scrum the team may decide that a Story or Stories will not be completed by the end of the Sprint. Make sure you are involved in the Daily Scrums to keep informed which Stories won’t make the Sprint.

  14. Triaging - Do you understand that all feedback will be worked on in the next Sprint?

    At the beginning of a Sprint, the team will commit to getting a certain subset of the Backlog completed. This is only possible if they focus only on work that is in the Sprint.

    To aid with this, any new requests or feedback received during a Sprint will go into the Backlog to be prioritised and potentially added to the next Sprint if its priority is more than other items already in the Backlog. The exception to this is if a critical bug is found that gets in the way of the items in the Sprint being counted as "done".

  15. Watch - Do you disclose existing issues?

    No doubt there will be a time when you get new developers to work on an existing application. Known issues with the existing application should be clearly delineated as much as possible. But new bugs will occur when changes have unforeseen effects on functionality down the line. This is to be expected.

    1st, make sure any known bugs are tracked in the backlog.

    Then, generally you should prioritise any important bugs in your backlog to get rid of them asap. the longer a bug exists, often the more expensive it ends up being to fix.

    Lastly, ask your developer to add a test case which will mean that in the future, important functionality will never "disappear" or break. The earlier you do this, the less pain you'll have down the track.

  16. Watch - Do you conduct user acceptance testing thoroughly?

    The shorter the time period between development and testing, the quicker and easier it will be to solve any issues identified during testing. When your developers provide you with a test version, have your resources available to review the version and get feedback to them straight away.

    Insist your software consultants run a test please with you and the client every week.

  17. Do your User Stories include Acceptance Criteria?

    User Stories are a great way to capture requirements, but it can be difficult to work out when the implementation of a story is complete.

    Acceptance Criteria (from the Product Owner) help to answer the question "How will I know when I'm done with this User Story?". It defines the exact requirements that must be met for the User Story to be completed.

    Acceptance Criteria are useful to every person who deals with a User Story. Developers know what they are required to implement and how their work will be tested. Testers have a basis for knowing what tests to create.

    What do good Acceptance Criteria look like?

    Product Owners should make an effort to specify all of their requirements for a story in the Acceptance Criteria. For example, Product Owners should not assume things like:

    • They will get a message that says ‘no records found’ or
    • The grid will support features such as pagination or sorting

    They must be specified in the Acceptance Criteria if required for the story to be considered complete.

    acceptance criteria detail
    Figure: A User Story PBI with Acceptance Criteria in Azure DevOps

    When I enter ‘Adam’ in the search box and click 'Search' I will see all entries starting with 'Adam' in the grid

    Figure: Bad example of Acceptance Criteria - Incomplete

    ::: greybox

    • When I enter ‘Adam’ in the Search box and click ‘Search’ I will see all entries starting with Adam in the Grid
    • When I enter ‘zzz’ in the Search box and click ‘Search’ I will see no entries in the Grid ::: ::: ok Figure: OK example of Acceptance Criteria - However the Product Owner probably hasn't included all of their requirements :::

    ::: greybox

    • When I enter ‘Adam’ in the Search box and click ‘Search’ I will see all entries starting with Adam in the Grid
    • When I enter ‘zzz’ in the Search box and click ‘Search’ I will see no entries in the Grid
    • If no results are returned, show a message box ‘No results found’
    • If no search text is entered, the ‘Search’ button should be disabled
    • Right-clicking on a column header should provide ‘Sort’ functionality
    • If a large set of results is returned, display pagination with page numbers and ‘Prev’, ‘Next’ links ::: ::: good Figure: Good example of Acceptance Criteria :::

    Note: For tiny User Stories, you can omit Acceptance Criteria. Sometimes you just need a screenshot or, even better, a video.
    Be mindful that such small User Stories are the exception and not the rule when it comes to the need for Acceptance Criteria.

    Negotiating "gold plating"

    Any requirements that the Product Owner considers "nice to have" - as opposed to being mandatory for the story to be considered complete - should be negotiated with development as early as possible. Developers can spend significant time working to meet acceptance criteria that the Product Owner is actually willing to sacrifice in the interests of quicker delivery.

    Tip: Work closely with the Product Owner to identify potential "gold plating" in the story. Suggest creating a separate story for the functionality that is nice to have but has lower priority. Doing so allows developers to focus on building the most important functionality for the story first and prevents valuable time being wasted on gold plating.

    Technical Acceptance Criteria

    Sometimes, the team may discuss including technical requirements in Acceptance Criteria. Typically, technical Acceptance Criteria should be avoided. However, there are some situations where it makes sense, such as when:

    • The team is trying out something new
    • The team has been misaligned in the past, and the future direction needs to be clear
    • The approach to take is complex or confusing
    • An abnormal approach is being taken to avoid a specific issue (e.g. Reducing readability to improve performance for a particularly critical query)
    • When the User Story is an Enabler (backlog items that extend the architectural runway of the solution under development or improve the performance of the development value stream)

    If technical requirements are added, it should be a discussion between all of the developers in the team. If the Product Owner is technical, they are welcome to join the conversation, but they should not be the primary decision maker in this case.

    Additionally, when adding technical requirements try to prefix with "Technical - " so their purpose is clear to everyone (e.g. "Technical - New CQRS Query made to get all employees")

    Acceptance Tests

    Since Acceptance Criteria will be used to determine whether the work for the story is done or not, each of them needs to verified using an Acceptance Test.

    It is good practice to make sure that each of the Acceptance Criteria is testable (e.g. Tests can be written to definitively determine whether the criteria has been met or not). This can help to reduce vagueness in the way Acceptance Criteria are defined.

    Note: When all of the acceptance tests pass, the User Story might be acceptable - but deeper testing would be required to be more certain. When any of the acceptance tests fail, though, we know for sure that the User Story isn’t acceptable. It can be helpful to think of "Acceptance Tests" instead as "Rejection Tests".

    What's the difference between "Acceptance Criteria" and "Definition of Done"?

    Acceptance Criteria help to answer the question "How will I know when I'm done with this User Story?". The Acceptance Criteria are different for each User Story, provided by the Product Owner and used as a way to communicate to all involved that the requirements for a particular User Story have been met.

    The Definition of Done is a structured list of items, each one used to validate a User Story, which exists to ensure that the team agrees about the quality of work they’re producing. It is defined by the team and serves as a checklist that is used to check each User Story for completeness. The definition of "Done" is intended to be applicable to all items in the Product Backlog, not just a single User Story.

    Examples of items in a Definition of Done that would not be part of Acceptance Criteria include:

    • Code review completed
    • Unit tests passed
    • Code deployed to production

    The term "Definition of Done" is defined in the Scrum Guide, while "Acceptance Criteria" is not.

    Capture changes to the PBI from discussions

    The Acceptance Criteria are the source of truth for what functionality needs to be implemented for the PBI to be considered complete, so it's important to capture any changes to the PBI and the Acceptance Criteria (e.g. adding or removing "nice to have" aspects of the story).

    Any discussion that changes the story and/or the Acceptance Criteria should be noted in the Discussion section of the PBI for reference.

    acceptance criteria discussion
    Figure: Good example - Discussion about changes to the story and Acceptance Criteria captured in the PBI

  18. Watch - Do you get regular updates on costs and progress (aka Project Progress, Burndown, etc.)?

    You're the one paying the bills, make sure you know where the costs are and how the project is progressing.

    Insist on receiving these 3 reports in every Review meeting:

    • Project Progress ($ spent)
    • Burndown (ETA)
    • Story Overview (testing quality)

    Let's look at those 3 reports:

    1. Current project costs

    This allows you to see the actual costs of the project on a weekly basis.

    Figure 1: Project Progress – There is $30k spent and $8K outstanding

    2. Current hours remaining and hours completed for the current Sprint

    Figure 2: Burndown report - Shows the progress of the team in the current Sprint – ETA is March 29 and Ana has no work to do

    Questions that the Burndown and Burn Rate report help answer:

    1. Is the team likely to finish the iteration on time?
    2. Will the team complete the required work, based on the current Burn Rate?
    3. Has the team added work to the iteration?
    4. How much work does each team member have?

    See how to use the Burndown and Burn Rate Report.

    3. Story Overview - See how each task is tracking

    Figure 3: Stories Overview report - Shows the progress of the User Stories in the current Sprint and nothing has been tested and no active bugs

    Questions that the Stories Overview report help answer:

    1. How much work does each story require?
    2. How much work has the team completed for each story?
    3. Are the tests for each story passing?
    4. How many active bugs does each story have?

    See how to use the Stories Overview Report.

  19. Watch - Do you get Sprint forecasts?

    At the beginning of each Sprint, you will receive a Sprint forecast that explains what the developers will be working on in this Sprint.

    It's very important that these are your highest priority items as these will be prioritised over anything else for this Sprint. If you want any changes made, contact the team as soon as possible.

    For more information on Sprint Forecasts, see Do you create a Sprint Forecast? (aka The functionality that will be developed during the Sprint)

  20. Watch - Do you know what is going on?

    We've all heard horror stories of tradesmen causing chaos: "I asked them to fix a tap, but after the sink broke we had to move out for 6 weeks while the carpet was dry-cleaned and new floor-boards were laid." This problem generally occurs after you have let the supplier have a free-for-all in your house while you're at work: "Just let yourself in, the keys under the mat, and get the job done".

    My Father-in-Law is Greek and I have noticed he gets more out of a tradesman than anyone else. Bottom line is he watches what they're doing and then gets on their case early when things aren't perfect. Whether it's carpet layers not matching the patterns together or plasterers leaving unsightly corners - as soon as he spots a problem he confronts them straight away and gets them to rectify it.

    This holds true for software development too.

    You should always take a hands-on approach with the project, stay on top of the important issues, and be ready to get involved when you see a problem.

    Of course, as your relationship builds, and they become more aware of your expectations, you can divulge greater trust and leave them to it.

    You should insist that your software consultants maintain verbal contact with you (before resorting to emails).

    They should then use “as per our conversation” follow up emails.

    Tip: A nice way to know what is going on is going on is to turn up to the Daily Scrum.

  21. Do you know the costs of old versus new technologies?

    Every new project faces the question "What technology should I build this solution in?". There are pros and cons to choosing new technologies over old ones:


    • Productivity improvements (faster and cheaper development)
    • Less conversion issues later
    • Happier Developers
    • Potentially a competitive advantage
    • Development environments are likely current and so don’t need time to setup


    • All issues are not necessarily known yet and workarounds may need to be found
    • Backwards compatibility (you may have users who have to use an older platform and new techs may not work for them)

    One major issue with using old technologies is that you will often be up for additional costs to set up suitable legacy development environments. i.e. SQL 2005 Server, Windows 7 running VS2008 etc. and then there are bills for ongoing charges (if required to host and store dormant VMs)

  22. Do you know how to manage the Product Backlog?

    The Product Owner (PO) is responsible for managing the Product Backlog. This includes the following:

    po tasks
    Figure: PO responsibilities regarding the Backlog from the “What is a Product Owner” video

    1. Create clear PBIs
    2. Order them by priority level
    3. Make sure they’re useful to the business
    4. Make sure everyone knows how to view the backlog
    5. Clarify any unclear PBIs as needed
  23. Do you estimate “Business Value”?

    You do Scrum, but do you use the "Business Value" field?

    That's OK, most teams don't... but it is a shame, because developers go to the trouble of estimating 'Effort' and if you have Effort, all you need is Business Value and you can calculate ROI.

    Once you have ROI a Product Owner can use the ROI field to sort priority. Awesome.

    ROI (Return on Investment) is an unbelievably simply calculation.

    business value field
    Figure: Product Owners should be estimating the Business Value

    ROI = Business Value / Effort

    ...of course there are other factors to consider.

    E.g. Risk, Dependencies etc and you could make the formula more complicated....

    Priority = (Positive Value - Negative Value) + Risk + Dependencies / Effort

    ...but don't bother.

    The Product Backlog is just a list of items with rough estimates of both development 'Effort' and 'Business Value'. You will find that ROI will tell you great stuff. It is especially useful for finding the easy high value items to kick off a Sprint.

    Product Owners are too busy for this

    If it is good enough for developers to estimate story points... then it is good enough for the Business to estimate Business Value. Usually devs will use the Fibonacci sequence, but since it is a good idea that the business guys use the same scale, it is best to switch to the doubling method of estimating - Do you know how to size user stories effectively?

    For example, if the "add rich text box" and "add sortable column headings on the grid" have the same business value of 3, the one with the smallest development effort will have higher priority (the ROI is greater).

    In summary, the simple calculated field ROI, can automatically order the backlog tasks for the Product Owner, makes estimating Business Value just good sense.

    PBIs can provide value in several ways:

    • Commercial Value: How does this item increase our revenue or profit?
    • Efficiency Value: How does this save us time or money?
    • Future Value: How will this save us money or time in future?
    • Customer Value: How does this increase the likelihood that a customer continues to use our project?
    • Market Value: How does this allow us to attract more users or customers?

    For more on this see Five Types Of Value |

  24. Do you give your emails a Business Value?

    The problem with emailing a task, is that no one knows how important that email is, in relation to all their other emails. So, what is the solution?

    People can send tasks in different ways:

    1. Send a simple email with no priority indication

    Email sign
    Figure: Bad example - An email with requirements does not indicate the priority

    1. Put the task straight into the backlog in the desired priority order, but send no email

    straight to scrum
    Figure: Bad example - The developer does not get a chance to ask questions and refine it before it hits the backlog

    1. Send an email indicating its priority. The recipient reviews it and places it into the backlog, based off the specified Business Value

    Developer entered
    Figure: Good example - Email tasks with a Business Value, allow the developer to review before putting it in the backlog

    The perfect email workflow

    Before you email a task to someone, think about how important it is to you. Then draft your email, add the Business Value using the same scale that you would use to estimate your PBIs.

    Email Diagram
    Figure: Good example - The best workflow for sending an email

    What if you need to write an email to multiple recipients?

    Assign each person a Business Value. In the case of "To Myself" emails, you can also add the amount of 'Effort' required too.

    Email screenshot
    Figure: Good example - The best workflow for sending an email with multiple recipients

  25. Do you know the importance of paying back Technical Debt?

    What is Technical Debt?

    Technical Debt is when you defer work that needs doing in your code. And, just like when you defer a payment and accrue financial debt, Technical Debt must be repaid, and it accumulates interest (in the form of reduced velocity) while it remains unpaid.

    Technical Debt can occur for all kinds of reasons, for example:

    • When you take a shortcut or implement a hack to get a feature out quickly. Sometimes this is because, as a team (including the Product Owner), you've made a conscious decision to take this shortcut because, for example, you need a cut-down version of the feature urgently, or in other cases because of an open bug in a library you depend on.
    • Code that is hard to understand after reading it multiple times or a single method that spans multiple screens is also considered to be Technical Debt.

    Systems need to have features added to them to continually remain useful (or competitive). As new features are added to the system, often more Technical Debt will be introduced. But as any system ages, it will accumulate Technical Debt.

    IMPORTANT: When you become aware of Technical Debt in a product, you must add it to the backlog. Whether you have discovered the Technical Debt or added it intentionally, either way the discussion and decision must be recorded in a PBI. This allows the team to factor paying it back into their Sprint planning.

    Example: A developer takes a shortcut to get some early feedback on a new feature

    • $100 - full feature
    • $20 - feature with shortcuts (no tests, dirty code, whatever it takes)
    • $80 - IOU via PBI in the backlog e.g. [FeatureName] – Technical Debt - Planned

    waf tech debt backlog northwind 1710232021944
    Figure: Good example - Technical Debt is very visible to the Product Owner

    What are the consequences of Technical Debt?

    • Fewer features over time for the customers
    • More molasses (developer friction) for the developers

    The 3 types of Technical Debt

    1. Planned Technical Debt

    Sometimes you want to quickly implement a new feature to get it out and receive some feedback.

    PBI: [FeatureName] – Technical Debt - Planned

    Note: Martin Fowler calls this "Deliberate Technical Debt".

    2. Discovered Technical Debt

    During a code review, you or the team notice something as part of the system that is clearly Technical Debt. This code is hindering the ability to add new features or is hard to read/understand.

    PBI: [FeatureName] – Technical Debt - Discovered

    Note: Martin Fowler calls this "Inadvertent Technical Debt".

    3. Unavoidable Technical Debt

    Every system will accumulate Technical Debt over time. For example, if you built an API with ASP.NET Core 2.0 (which is now out of support), you have Technical Debt because that version is no longer supported. This kind of Technical Debt cannot only negatively impact the productivity of the team, but it can also introduce a security risk. Another example is that the architecture you selected may have been right based on the original spec, but as requirements change or new requriements emerge, this may no longer be the case. The team can choose to refactor now, or accept the Technical Debt and continue to deliver features on the current architecture.

    PBI: [FeatureName] - Technical Debt - Unavoidable

    Note: Martin Fowler would also classify this as "Inadvertent Technical Debt".

    How to repay Technical Debt

    Just like a business that receives pre-payment from customers, a software team should be reviewing the size of their liabilities (being the list of PBIs with Technical Debt).

    At the Sprint Planning:

    1. Show the Product Owner the list of outstanding Technical Debt PBIs
    2. The Product Owner should make sure that the developers review the list of Technical Debt list and pick at least 1 PBI to pay back during the upcoming Sprint


    techdebt github
    Figure: Screenshot of code with Technical Debt comment and link to GitHub issue

    techdebt backlog
    Figure: Screenshot of Technical Debt on backlog

    techdebt architecture
    Figure: SugarLearning architecture diagram

  26. Do you use "Stories Overview" report to find out where the project is at?

    A common question for every project manager is "where is my project at?" This question isn't just asked to find out how many tasks are done, but also to understand if all these tasks are done to meet users' requirements.

    Both the Visual Studio Scrum and MSF for Agile project templates in TFS 2010 and 2012 provide a built-in "Stories Overview" report to help you find out where the project is at, as well as to tell you if all the tasks are well tested.

    84d04e StoriesOverviewReport
    Figure: The developer says he is 90% done... the report shows 25% tested, but 0% passed!

    Tip: Set this up on a daily schedule so the Scrum Team get this in their inbox each day.

    Suggestion for Microsoft #1: Add a Summary Number in large font at the top, eg. 55% complete.

    Suggestion for Microsoft #2: Add this great report to the Microsoft Scrum TFS Process Template.

    Where are we at?

    "TFS’s Stories Overview Report is the best tool to solve the common question project managers ask the developers “Where are we at?”

    The problem with the answer is that developers almost always say 90%"


    Need to know $$$? Read Do you get regular updates on costs and progress (aka Project Progress, Burndown, Story Overview)? to see which reports you need to get a complete project progress overview.

  27. Product Owner - Do you know how to build/update the backlog?

    The Product Owner is responsible for owning the Product backlog. See the video on "Do you know how to be a good Product Owner?"

    How to add new PBI (Product Backlog item) to the backlog?

    Do not use emails as you can't order them by the business priorities.

    Use Azure DevOps (E.g. as it allows you to enter an item into the backlog, in the preferred priority order.

    Figure: Good Example - Azure DevOps allows you to enter an item into the backlog, in any priority order

    Note: You can also create a PBI using Azure DevOps and attach an email directly if needed, without using Team Companion

  28. Triaging - Do you correctly triage additional item requests?

    "Triage" is a term originally used to describe the assessment of injured persons into a priority order based on the severity and urgency of their injuries. While developers don't often deal with real life and death situations, the ability to prioritise and action issues that arise can keep the heartbeat of a project steady and strong.

    Managing additional work requests can reduce the adverse impact on estimates and deadlines. These work requests can include new feature requests, non-critical bug fixes, modifications and undiscovered work (i.e. work you didn't initially anticipate).

    SuccessfulProjects Triage
    Figure: Only if it's life and death does it get added "in this Sprint"


    The first step is to prioritize the new work item.

    1. If it is a critical bug, call your Product Owner and add it to the current Sprint
    2. Otherwise, it should be added to the backlog:

      1. If the item is assessed as important, it should be placed immediately after the current Sprint items
      2. Otherwise, you should attempt to prioritize the item based on the existing items in the backlog

    Note: On a fixed price contract, the rules change. Bugs should be fixed in the current Sprint if time allows, otherwise first thing in the next Sprint as they are stopping you from being paid.

    Exception #1 - Critical Bugs go into the current Sprint

    If you have a crash-to-code bug, most of the time it will go into the current Sprint. If it prevents one or more users accessing the system, it will also go into the current Sprint. High-priority bugs are fixed "in this Sprint".

    Bugs are usually prioritised, so even non-critical bugs will likely end up in the next Sprint (via the Backlog).

    Exception #2 - A client can override

    A request for a new screen with a new look-up table that doesn't prevent users from operating the system, should be allocated to "a later Sprint".If the client really needs it done now, they must specify "must be in this Sprint". This will become an 'additional item' in the current Sprint.

    If this request from the client will have a material impact on inflexible time and budget restraints, you need to speak and inform the client.

    For example: "Hi Bill, this task you specified 'must be in this Sprint' will take an extra 4 days. Our critical deadline will be missed. Is that OK?"

    Exception #3 - A Developer can override

    A client may request a small feature (e.g. changing the sort order of a combo-box). This work can go in the current Sprint as long as the task is small (less than 1/2 hour) and the Sprint is not already slipping.

    If the work is over budget, then you need to obtain approval for any 'additional item', from both the project manager and the client, before adding the request into the Sprint. See more about how to obtain approval for additional items that exceed estimates.

    Figure: The above email sample from a customer will, by default, go into a future Sprint, not the current

  29. Stakeholder Management - Do you know how to disagree with powerful stakeholders?

    Disagreeing with powerful stakeholders can have a huge impact. It's always good to speak up, but a poorly worded disagreement can result in misalignment or frustration. That's why it's crucial to frame your messages in a way that ensures ideas are expressed effectively.

    Video: How to Disagree with Someone More Powerful (watch 3 min from 3:06-5:38)

    Imagine a scenario where you are a Developer on a team and you disagree with the Product Owner about the priority of your PBI - migrating from .NET 6 to .NET 8. The Product Owner is saying they don't want to do it, but you think it's important for this Sprint.

    Let's see what tips and tricks can be applied to ensure a smooth discussion.

    Align your interests and understanding

    When you have a disagreement with a senior colleague, it's likely that you have different perspectives and understanding. Before you talk about the issue, it's pivotal to check you are on the same page about the issue and looking for a path forward. Here are some tips for doing so:

    1. Repeat your understanding of the issue
    2. Ask if they're open to feedback
    3. Find a common target

    1. Repeat your understanding of the issue

    By repeating back your understanding of the issue, you can check that their viewpoint aligns with yours, and if there are any discrepancies, they can be caught before the issue is discussed. (aka Steelmanning)

    Developer: I think you don't want to migrate from .NET 6 to .NET 8 because you want to finish adding single-sign on first. And you consider any security issues to be priority 1. Is that correct?

    Product Owner: Actually, the reason is because .NET 9 comes out in a few months and I want to wait for that version.

    Good example - The Developer identified that the Product Owner had a different reason than they thought

    2. Ask if they're open to feedback

    Getting permission to comment is a great tactic. It makes the stakeholder feel empowered to have the conversation and also gives you confidence that they are interested in what you have to say.

    Developer: Would it be OK if I explain why I think we should upgrade now?

    Product Owner: Sure!

    Good example - The Developer gives a warning to the Product Owner to check if they are in a moment where they are ready to listen to a dissenting opinion

    3. Find a common target

    Determine an outcome you both want to see from the solution. That way the conversation centers on delivering business value rather than being contrary for the sake of it.

    Developer: Lately, our users have been having significant performance issues, and that has been a pain point. Would you agree?

    Product Owner: Yes, absolutely!

    Developer: Well, when I read the .NET 8 release notes I saw they have improved performance by 20%. That's why I want to upgrade now.

    Good example - The Developer identified a pain point the Product Owner cares about, strengthens their argument

    Keep the dialog focused on the issue

    When talking with a powerful stakeholder it's vital to keep the conversation on track and focused on the issue itself. Here are several strategies you can use:

    1. Ground yourself in logic
    2. Avoid judgemental language
    3. Express that it's your opinion
    4. Leave it up to them

    1. Ground yourself in logic

    When communicating about a problem, emotions can quickly get in the way. You want to project confidence and neutrality - that's why it's critical to try and stick to the logic and facts.

    2. Express that it's your opinion

    If you caveat that you are just expressing your opinion, others will feel like you are open to discussing the issue rationally and that you understand others may disagree.

    Product Owner: I don't want to upgrade to .NET 8 this Sprint because I want to wait for .NET 9

    Developer: No, we should upgrade to .NET 8 this Sprint because it will help fix users' performance issues.

    Bad example - The Developer didn't express that it was their opinion.

    Product Owner: [See above]

    Developer: In my opinion, it's better if we upgrade to .NET 8 this Sprint because it will help fix users' performance issues.

    Good example - The Developer mentions that it is their opinion leaving the topic open for discussion.

    3. Avoid judgemental language

    Language that sounds accusatory or judgmental can evoke bad reactions and derail a conversation. Words like "stupid", "hasty", "naive" etc. focus the discussion on people's judgment rather than the issue itself. When that happens, you are no longer discussing the logical cause of the disagreement.

    Developer: It would be stupid if we didn't upgrade to .NET 8 this Sprint

    Bad example - The Developer made their point and it sounds like a personal attack

    Developer: If we don't upgrade to .NET 8 this Sprint, our users are going to keep having the performance issues they have been complaining about.

    Good example - The Developer identifies a pain point for the users, rather than making it emotion based

    4. Leave it up to them

    Let them know it's their decision, but be clear that you disagree. Communicating this way allows them to feel in control but also makes it obvious what your opinion is.

    We should upgrade to .NET 8 this Sprint so that we can solve the performance problems users are experiencing.

    Bad example - Doesn't leave the power in the stakeholders hands.

    This call is yours, but my opinion is that we should upgrade to .NET 8 this Sprint so that we can solve the performance problems users are experiencing.

    Good example - Clearly expresses that the final decision is up to them

    Even if you follow all these tips, there is a chance the powerful stakeholder still won't agree with you. In this scenario, it's important to document your disagreement in a for the record email.

We open source. Powered by GitHub