Scrum tales - Part 13 - Remaining work estimate

Sprints and Tasks are ownership of Scrum team members and as such you are directly responsible for maintaining their integrity. Product Owner is only concerned with specific Product Backlog Items (goals), to get final deliverables as expected, and won't interfere with the Sprint Tasks

As each Task is owned by a single Scrum team member, if the task is not done at the end of the day, that team member must update the estimate in hours on how much work remains. The estimate should be as real as possible and should answer a simple question "How many more hours do I need in order to complete this task?"

Q: Can the work hours estimate be unchanged or even go up after working on a task?
A: Yes, but in such cases if your daily burndown Actual line also goes up you need to provide an explanation

Q: Where do I track how many hours I spent on a specific Task?
A: You don't. We only need to know how much work remains and to have as objective estimate as possible

Q: What if my Task takes several days to complete?
A: Refactor the Task to create several smaller ones so you can complete at least one Task each day; don't end a workday without finishing at least one Task

Q: What if our Tasks are too complex and cannot be split into smaller Tasks?
A: Unless your Task is an elementary particle, it can be split

A good sprint is a sprint that has concise Tasks so that each Scrum team member can complete at least one Task each day and provide a Daily deliverable

Scrum tales - Part 12 - Definition of Done

Common issue repeated in almost all Scrum teams is figuring out when a specific Product Backlog Item can be considered Done. What we haven't established but will be critical going forward is a commonly known and widely understood Definition of Done (DoD)


Let's focus first on what each goal / PBI should contain: Acceptance Criteria; this is a simple checklist explaining unambiguous deliverables required to consider the goal Done
Although each PBI is named so it can fit neatly in a straightforward question "Did you <PBI title here>?", answer is not always a simple Yes or No (providing a seam to exploit ;)) so it must be backed up by a more detailed acceptance criteria checklist

Who defines acceptance criteria?
Product Owners do. Scrum teams can help suggest goals based on Product Owner provided Epic stories, but Product Owner is directly responsible to define clear expectations for each PBI while grooming Product Backlog

How can we, the Scrum team, help?
Acceptance criteria is as important to a Scrum team as it is to Product Owner. By having clearly defined expectations it won't be possible for Product Owner to say: "Hey, you haven't delivered the product in a cardboard box which was obviously expected"
Just make sure that you are clear with all deliverable expectations while grooming the Product Backlog - ask your Product Owner for clarification on each unclear goal at this time. You cannot go back after you commit to PBIs in a new Sprint, Product Owner will expect to see deliverables in order to provide you with an OK in the end

What is the DoD then?
   1) Present deliverable to Product Owner as soon as it is ready
   2) Answer unambiguously Yes to all items in the acceptance criteria checklist
   3) Get an OK from Product Owner

If you followed through with the three steps above, feel free to mark a PBI Done

Production roadmap demystified

To escape the arbitrary process of determining production roadmap we need to instate a scientific and clear system to satisfy business needs and have unambiguous priorities for both products and their functionality. Production roadmap will be defined in few simple steps:
   1) Create empty slots for product releases per each developer team based on business (EPO) needs
   2) Perform Research and Analysis to determine clear priority list for new/existing product and their functionality
   3) Fill out the roadmap slots by following previously defined product/functionality priorities

Step 1 - empty slots creation
Owned by: COO with assistance of CEO/Sales

Business needs that guide creation of production roadmap empty slots:
   1. One possible release slot per core developer team per month (12 per team)
   2. 75% of empty slots are to be allocated for new High ROI products (9 "green slots" per team)
   3. Release one new major version for existing products each year

Step 2 - R&A rank lists
Owned by: DPD with assistance of other technical teams (Support, QA indirectly)

Singular system similar to what we use in HR - evaluate specific properties of each candidate, summarize, sort and create a clear rank list of recommendations to fill the "buckets"

We can distinguish 3 sets of properties* for 3 rank lists we need to fill out the empty Production roadmap slots:
   1. Possible new High ROI products (green slots)
   2. Existing products (purple slots)
   3. New/existing product changes/functionalities; prioritized list of features needed for each of the products we'll use to fill the allocated slots

*Specific properties for R&A product/functionality ranking will be detailed separately

Step 3 - filling the empty slots
Owned by: COO with assistance of DPD

With clearly defined business needs and R&A rank lists, filling the slots is objective process:
   1. Fill the green slots based on new High ROI products R&A list of priorities
   2. Fill the purple slots based on existing products R&A list of priorities
   3. Assign a minimum and maximum feature set to each product release; minimum feature set must be met, maximum only if there is enough time and resources allocated but not for the expense of delaying the release
   4. Proof the estimates with developer teams to establish a commitment of both sides: no changes on requirements side and no delays on developer side


Do's and Don'ts
   A) Do apply lean techniques for new releases: make each new product release as short as possible with minimum possible feature set needed to determine the success of the product; analyze first version results and make a clear decision to pivot or persevere

   B) Do plan and proof estimates conservatively to make Production roadmap predictable and solid for the entire year

   C) Do use priority pairs to determine the weights of business needs if something's got to break; i.e. New High ROI products > one major release for all existing products each year

   D) Don't assume available development resources are fixed but think outside of the box to satisfy all business needs

   E) Don't push back planned releases but instead cut out lower priority features to release on time

Product release notes - why do they matter

Everyone involved in pre or post-production is writing product release notes: developers, QA and Support. In the end release notes for all products appear consistent and are published following carefully constructed set of internal writing standards. Here's an autopilot plan listing release notes creation process in top-down priority by owners


Support

You are the direct owners of product release notes; they serve as proactive help and guidance for our customers by letting everyone know what we improved, changed and fixed in the new product releases. Having good release notes has multiple benefits:
   a) Satisfied existing customers
   b) More new customers
   c) Less need for later reactive support

This means that you have the final and ultimate responsibility to polish the release notes for all products before the release, make them consistent and easy to understand for all and push to production. To do so, use all the help you can from other teams (QA, developers) to clarify required technical details and rewrite the release notes as needed

Release notes standards are there to make all release notes consistent, not to create more bureaucratic overhead; if you see a way to improve it by making release notes simpler and easier for customers to understand - act on it now


QA

You write the most of the release notes from scratch as soon as Bugs are reported which basically makes you the main authors of 90% of all our release notes. Writing good release notes has multiple benefits:
   a) Release note text can also be directly used as Bug title - two flies with one swat
   b) Bug title matching well written release note will make developers understand bugs more easily and will pull on your sleeve less often
   c) Save time for Support which in turn allows them to resolve more reactive support issues, to forward less issues to you and thus save your own time


Developers

You are the first and the last line of defense - you consolidate all release notes for a new product release into one file on start and incorporate them back into product after Support team reviews them

Yes, you still have to write all enhancements and changes as no one else knows what has improved and changed in the product better than you. Additionally you have the responsibility to incorporate final release notes back into your product and to make sure formatting is consistent across all products

As Everyone Serves, your main job is to provide prompt technical assistance to other teams when they need to write a good and simple release note


Common suggestions

   1) When in doubt how to write a release note just put yourself in customer's shoes and see if an outsider will understand it after a single read
   2) Make all release notes as concise as possible - they are not help content but new product version proactive one-sentence guidelines
   3) Describe anything and everything that has changed and especially improved in new product releases, even if you accidentally improved performance by a few percent
   4) If not sure how to write a release note contact other teams for assistance - don't write a poor and inconclusive release note as it will eventually come back to you

Scrum tales - Part 11 - get back on track

Let's resolve two distinct sprint issues that have repeated several times in various Scrum teams:
   1) Team member who was counted on has left the team, got sick, had to work on new critical priority tasks not anticipated with the sprint = sprint fails
   2) All team members are accounted for and are working but the sprint burndown shows the team is late halfway through the sprint = sprint fails


1) What do we do when team resources change during a sprint?
Sprint grooming. This is an unofficial Scrum team meeting organized by ScrumMaster with a single purpose: accommodate the sprint tasks to change in Scrum team resources

Specifically if the team has lost a team member, organize a quick team meeting and see how many hours are taken away from the sprint starting from the current date until the end of the sprint, then just remove corresponding number of tasks from the sprint bottom up (lowest priority ones)

Similarly if the team has gained a new team member, organize a team meeting and see how many additional hours you have gained until the end of the sprint, then just append that many tasks to the sprint

   a) Don't change team Projected hours - leave the original burndown graph line intact for comparison as all changes will be immediately reflected in the Actual line
   b) Do mention to Product Owner in daily Scrum summary that the sprint has been groomed and how many hours have been taken away or added to the sprint


2) What do we do when we are obviously running late (above the Projected line) midway through the sprint?
Roll up your sleeves and burn some midnight oil to catch up ;) Remember that the whole team has taken part during the Sprint planning meeting to estimate work ahead and that you had plenty of chances to include research and analysis tasks to get better sense of work needed. There's plethora of reasons why you're behind but there's only one solution - switch into higher gear to catch up

   a) Don't perform sprint grooming in this case unless team resources have changed
   b) Do include detailed description to Product Owner in daily Scrum summary what you are planning to do to catch up and what have you done already

   c) Don't ignore #b ;) all daily Scrum summaries must include Catching up notes section if you are running late in the second half of the sprint