Affinity Estimation

“Affinity Estimating is a technique many teams use to quickly and easily estimate (in Story Points) a large number of user stories. This is a great technique if you’re just starting a project and have a backlog that hasn’t been estimated yet.”

I remember this topic came up during the ScrumMaster course and I found it quite interesting, I’ve finally found an article related to it on Kane Mar’s blog, have a look at the entry here.  I’ve yet to try it but will when I have a project with a huge amount of stories, it sounds like it can work quite well.


Impediment: That which impedes or hinders progress, motion, activity, or effect.

I’ve been thinking about the negative context “impediments” are sometimes set in, I don’t think impediments are negative at all, in fact quite the opposite, they are the pointers that lead you on the path of improvement, but it all depends on how you approach it I suppose. I think the important thing to remember is that there is a distinct difference between removing the SYMPTOM of the impediment versus removing the ROOT CAUSE. Yes, both will have the effect of enabling the team to continue, but fixing the ROOT CAUSE will lead to a permanent improvement potentially across the organization, you may even end up removing OTHER teams impediments!

A good example of this is something I myself had to deal with. Our team(s) rely heavily on a web service supplied by another part of the organization. Occasionally this web service supplier will do routine maintenance and bring down the service without informing anyone, bring development to a grinding halt. Our current way of removing this “impediment” is to contact them and request they restart it as soon as possible (fixing the SYMPTOM). A better solution would possibly be to set up a meeting with them and discuss how they can involve us in their maintenance planning, or at least inform us up front of scheduled maintenance, allowing us to plan ahead for these down times (aimed more at the ROOT CAUSE).

Talking to non-agile people…

As much as I know (or think I know) about Scrum I still find it difficult some times to communicate to non-agile (waterfall) people that are resistant to change and passionate about their point of view. An interesting article I found clarifies this a bit for me, specifically how to communicate with project managers. The essence of it is to communicate to them in their own language, in terms they understand and can relate to. The article can be found here:

How to Talk to Project Managers


Epiphany: a sudden, intuitive perception of or insight into the reality or essential meaning of something, usually initiated by some simple, homely, or commonplace occurrence or experience.

I’ve always struggled with accepting the concept of estimating using story points and NOT effort hours. I could never get my mind around the concept and yes, I’ve read a lot about how estimating with hours is bad (people pad, management argues that real time <> estimated time, team members feel pressured etc etc…), and I believe this, however I did not understand how bad it was until today.

During our estimation (still doing hours effort estimation) we were trying to define the tasks necessary for a story to be completed, however the story had a “task A” that would lead to several “task B’s” that were known, however no-one could (and neither should they be expected to) estimate the hours effort on the “task B’s” simply because the input from “task A” was critical to the timing! Now you’re stuck with tasks that are KNOWN, but cannot be TIMED. And then the light went on and I realized why estimation with time was so bad…You may KNOW everything you need to do (the complexity), however you may not necessarily know how LONG everything will take (the effort), in other words, you know COMPLEXITY but you cannot measure the EFFORT. It now makes sense…


This is always a highly contentious and relative subject, what does a team mean when it’s DONE? This sort of popped into my head a while ago when I was contemplating how a person would go about making sure a team is actually performing as best they could, without interfering. My question was this, because Scrum is essentially a management process (and yes I know, its not only a process but also a “way of life” and a “mind shift”), and not an engineering process, a “green” team may not realize that a solid engineering process was missing from their way of working? Would it be your responsibility to point this out and prevent future technical debt building up, or should you leave it to the team to inevitably “fail” and attempt to fix the problem then?

Based on the input I had to this question I believe that part of the ScrumMasters role of ensuring process was being adhered to was to make sure the team had a well defined definition of “DONE”, and not only that they adhered to it but that they attempted to improve on it during retrospectives. “DONE” then becomes the instrument by which the team improves HOW they do things and can include good engineering practices like continuous integration, unit testing and essentially anything the team believes will improve the quality of their shippable product.

Along these lines I found a great article on the Scrum Alliance website by Mitch Lacey titled “How Do We Know When We Are Done“, which includes an exercise a team can go through to help them define their “DONE” list. I haven’t tried this yet, so I cannot speak from experience, but in principal it sounds good and I’m hoping to try it at the next available opportunity.

Are you really Agile?

I found this interesting article by James Shore:The Decline and Fall of Agile which essentially talks along the subject of people claiming to be “agile” but are not really and having this potentially destroying the true “agile” drive. People should be careful that they don’t just grab at buzzwords and ideas without realizing what they’re getting in to, especially with Scrum:

“But because Scrum works in short cycles and doesn’t include any engineering practices, it’s very easy for teams using Scrum to throw out design. Up-front design doesn’t work when you’re using short cycles, and Scrum doesn’t provide a replacement. Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt”

Read the full article, it was an eye-opener for me, and be careful, Scrum alone does NOT make you fully agile, it’s only a small step towards agility.


Someone told me something interesting the other day…”Silo’s destroy Scrum”, which I found interesting but never fully understood the impact until today. We’re approaching the end of our sprint and only one of the stories has been completed, a severe bottleneck was building up with the test work and when the team approached the “tester” within the team that was assigned to us with the offer to have them help out with testing, they were told that only she is allowed to “sign off” testing. I explained that this would cause the sprint to fail because there’s no way she could sign everything off in the remaining time but they were not interested, I guess they’re more interested in sticking to their silo’s than the project succeeding. There’s not much more I can do about this other than to point out that the sprint will fail and just let them fail…

Scrum in a Nutshell

I found a nice, concise, description of SCRUM here:

Scrum – a knol by Dan R Greening

I found particularly interesting the first comment made that clarified my questions regarding the fundamental difference of the feature/story point estimation vs the task/hours estimation techniques. It appears that the reason is pretty much around the comfort of the team and their willingness to participate effectively in the estimation process. I strongly suggest reading it…

The (Self Organizing) Team

The sprint planning sessions are taking long but this is because these concepts are new to the team. They need to be taught that they are the owners of their own destiny and as a team they, and only they, must move forward in this. The current way of working is way different, generally involving one or more managers dictating what needs to be done and being micro-managed until it’s done. I can see how this demoralizes people (myself included), afterall, doesn’t this send out a clear message that people don’t trust you to do something? And if someone doesn’t trust you how can you feel any pride or joy in what you do? I like the opening statement from “Agile Software Development using Scrum” saying “work can and should be an ennobling experience” , this is so true but people forget this… I think SCRUM is a way of bringing this back, a sort of “re-ennobling” process.

Anyway, I was pleased to see the team engaging (for the most part, I’m not expecting miracles yet) each other about the backlog, I do find though that I need to continually poke them to get them to start up, but they seem to be getting the idea that it’s all in their hands. I do need to be careful not to interfere too much though. The team has now managed to break down the user stories into reasonably well defined tasks that they need to perform to achieve success in this sprint, tomorrow the first scrum will happen and the team will commence with their work.

I did notice a interesting thing though, we had several questions and ideas we wanted to try during the sprint (one of the stories is overly complex but cannot be decomposed) and after the meeting the team seemed to spontaneously “self organize” in such a way that people who were best suited to do this “investigation” in various parts of the system automatically started doing it, this without prompting or “managing” them in the correct direction, all this before the sprint actually started! I found that pretty amazing…Let’s see what tomorrow brings.

As a side note, I’ve thought about the potential impediments to the upcoming sprint:

  • Micro management and interference from management.
  • Priorities changing.
  • Outside interference from other projects.
  • Production issues.

I’ll need to deal with these as they come up. I may not make any friends, but I will make this sprint succeed…