Rules to Better Product Owners
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:
In order to be a good PO, they need to:
- Be available for Sprint Reviews, Retrospectives and Sprint Planning meetings (approximately half a day for these 3 meetings, for each 2-week sprint).
- Order the Product Backlog. The important things will be done first, in order to maximize the ROI as the budget will run out one day.
- Be available, at least remotely, to unblock a developer if he has questions/impediments. A good PO has a feeling of urgency.
- Ideally, listen in on Daily Scrums. This is optional but means that the PO will have daily insight into the team’s progress.
- 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.
- Set a Product Goal (the "why" of the Product)
- Agree on a Sprint Goal for each sprint (the "why" of each sprint)
- Not influence (or anchor) developer estimates with comments like “this one will be easy” and allow the team to come up with converged estimates.
- Respect the Sprint Goal. Understand that the team will only work on things in the Sprint Backlog and don’t expect other things to be done as well. 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 with a personal stake in the success of the project.
- Someone who is available
- Someone with a clear vision of the product,
- Someone who has authority with the budget. E.g. They could authorize adding a designer to a sprint for a couple of days
- Someone who has read the Scrum Guide and 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, Scrum.org, during a TechEd session
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.
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.
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.
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.
Depending on how much visibility you need on ongoing costs, you will have to decide whether to use 1 or 2 week development iterations.5
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.
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.
#1 For Scrum Projects:
In Scrum projects, the role of a Project Manager is split into three roles: Scrum Master, Product Owner, and Team. Each role is essential.
When you're scoping the work to be completed, ensure you are as accurate as possible in your requirements.
"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 per Item
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 three other forms that the same type of combo appears on. So if you also want them fixed, then let them know about them!
Get UI Changes OKed
Insist your software consultants conduct specifications by creating mock-ups.
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
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.
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.
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.
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".
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.
Once again it's a matter of working with your developers in being clear in requirements and testing as changes are made to ensure these issues are trapped as early as possible.
Ask your SSW developer to add a test case which will mean in the future important functionality will never "disappear" or break. The earlier you do this, the less pain you'll have down the track.
The shorter the time period between development and testing, the quicker it will be to solve them. When your developers get you a test version, have your resources available to review the version and get feedback to them straight away.
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.
2. Current hours remaining and hours completed for the current sprint
Questions that the Burndown and Burn Rate report help answer:
- Is the team likely to finish the iteration on time?
- Will the team complete the required work, based on the current Burn Rate?
- Has the team added work to the iteration?
- 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
Questions that the Stories Overview report help answer:
- How much work does each story require?
- How much work has the team completed for each story?
- Are the tests for each story passing?
- How many active bugs does each story have?
See how to use the Stories Overview Report.
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)
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.
With any professional consultant or tradesman 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 with the consultant or tradesman, and they become more aware of your expectations, you can divulge greater trust and leave them to it.
So 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.
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)
The Product Owner (PO) is responsible for managing the Product Backlog. This includes the following:
- Create clear PBIs
- Order them by priority level
- Make sure they’re useful to the business
- Make sure everyone knows how to view the backlog
- Clarify any unclear PBIs as needed
OK you say you do Scrum, but do you use the "Business Value" field?
That's OK, most teams don't... but it is a terrible 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.
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.
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?
There are the 3 ways people can send tasks:
Figure: Bad example - An email with requirements does not indicate the priority
Figure: Bad example - The developer does not get a chance to ask questions and refine it before it hits the backlog
- Send an email, the recipient reviews it and places it into the backlog, based off the specified Business Value. Developers often prefer this method if they like control over their backlog.
Good example - Email tasks with a Business Value, allow the developer to review before putting it in the backlog
The perfect email workflow
Figure: Good example - The best workflow for sending an email
Figure: Good example - The best workflow for sending an email (with multiple recipients)
What is Technical Debt?
Technical Debt is when you take a shortcut to get a feature in to get some feedback.
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.
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] – Tech Debt - Planned
What are the consequences of Technical Debt?
- Fewer features overtime for the customers
- More molasses (developer friction) for the developers
The 2 types of Technical Debt
1. Planned Technical Debt
Sometimes you do want to quickly implement a new feature to get it out and receive some feedback.
PBI: [FeatureName] – Tech 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] – Tech Debt - Discovered
Note: Martin Fowler calls this "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:
- Show the Product Owner the list of outstanding Technical Debt PBIs
- 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
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.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.
The Product Owner is responsible for owning the Product backlog. See the video on "Do you know how to be a good Product Owner?"
There are three options for how to add new PBI (Product Backlog item) to the backlog:
Bad Example - This is a poor way to add a PBI as you can’t order emails by the business priority
- Azure DevOps - E.g. https://ssw.visualstudio.com
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
"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.
The first step is to analyse the priority of the additional item.
Let's look at the rules to how to prioritize:
- By Default, move Tasks into the Next Sprint. Priority is dependent upon the severity of the request. Only if it is a 'critical bug', then it will be done "in this sprint", most tasks however go "in a later sprint". They can include new feature requests, non-critical bug fixes, modifications and undiscovered work (i.e. work you didn't initially anticipate).
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 this Sprint If you have a crash-to-code bug, most of the time it will go into this sprint. If it prevents one or more users accessing the system, it will go into this sprint. Only high-priority bugs are fixed "in this sprint".
On the other hand, a bug that was in the prior sprint and not marked as a task in this sprint, generally will be moved into the next sprint. Everything in between is grey :-(
- 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 this sprint as long as the task is small (less than 1/2 hour) and the sprint is under budget. 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 Release Plan. See more about how to Obtain Approval Additional Items Exceed Estimates. To: Evan Lin - SSW From: Alan Ha - FinaMetrica Subject: Client List for Administrators
Please add a sort function (like the one in office 2007) next to the fields: Last Name, First Name, Advisers and Organization. Apply to other relevant pages which have these fields in a listi.e. adviser list for administrators, client list for advisers etc.Please use the text Ascending instead of "smallest to Largest" and Descending for "Largest to Smallest".
- Figure: The above is a sample from a customer will by default, go into a later sprint, not the current sprint.What tools can you use to get tasks from your inbox into a task tracking system? 5. **Use a Good 3rd party Tool to Manage Additional Requests ** Since most feedback comes into your Outlook inbox, find a tool that converts an email into a task. The best one is [TeamCompanion for TFS](http://www.ssw.com.au/ssw/Standards/DeveloperGeneral/TFS.aspx)