Why do we need to use assurance?

As said by the professor during the “Think again” course on Coursera, we use assurance just because we have limited time. So basically, sometimes it’s necessary to cut the crap and put the foot down before spending a ridiculous amount of time investigating all of the possible scenarios.

Very good point and another missing part in my BA repertoire


Scrums in geographically distributed teams

This is actually worth a separate blog and many separate discussions but I will at least start 🙂

As Henrik Kriberg puts in his book ” :o”

In Scrum from the trenches, Henrik describes the two approaches they’ve followed:

  • Separated teams (country based)
  • Separated team members (product based)

Right now we have a slight mixture of both with separated team approach prevailing. For now it’s unclear how to make this better so I will come back to this eventually

Scrum-of-Scrums Meetings

According to H. Kniberg’s “Scrum from the trenches”, their teams have had a weekly meeting known as Scrum of scrums where Scrum Masters from all of the teams (and products) gathered together to discuss the progress of each time.

Here is the link to Mike Cohn’s article on the Scrum of Scrums

In our project we have something similar and known as the product coordination meeting where Product Owners (we don’t have actual Scrum Masters) and their proxies (people like me) get together on gotomeeting to discuss where we are with the products. The purpose is to review user stories planned for the release (we don’t have a formal timeboxed sprint) and determine where we are in terms of completing features and not just user stories or development tasks.

Generally, these meetings are quite useful but a few items that we have now is an absence of any check of release health i.e. progress according to the schedule vs actual results.

This is a part of our other general problem – absence of a centralized requirements and project management approach (not just software but actually a process of handling requirements, team and project management).

Nevertheless, in this sense our team is in a good spot as we have product calls on a regular basis (actually twice a weeks but for different audiences) and we cover the two important questions:

  1. what progress was made in the last week
  2. concerns if any that should be raised

We are using Confluence to gather and store internal and client-facing requirements documentation. We are setting up release dedicated pages with the list of features for the release (committed, under discussion, completed) and review the resulting table on a weekly basis.


  1. difficult to prioritize as no visual indication of estimates for the feature (other than importance – high, med, low)
  2. as we don’t prioritize thoroughly, the implementation schedule for each feature is unclear
  3. we have a dashboard that explains each team member’s workload (based on tasks assigned from JIRA) but it’s not tied to the release to any extent

Product Team Structure and Product Calls Audience


More about planning poker

For a person with a hammer, everything is a nail. After trying planning poker for the first time, we have been trying to see how it can be used more extensively. And almost immediately we have run into a wall. With stories that are related to a very specialized domain, there is a learning curve that may significantly increase the time needed for making story point estimates. The question then is how meticulous the team should be in their estimates. If the hit-miss is around 80% of the anticipated work volume, this should be not bad at all but it depends on a few things

  1. how well does the team know the subject of discussion (in our case, SCORM that only one or two people out of our 10 people team have ever dealt with)
  2. how strong is the technical background of the team members involved into the discussion
  3. how busy the team members involved into the discussion are (if they are busy, they may prefer to give higher point value to a feature to defer it until the next sprint or so)