Definition of impediments in SCRUM

Scrum Impediments

Laszlo Szalvay of Danube talking about "impediments" in the context of Scrum:

"In the Scrum method of agile development, a scrum impediment is defined as anything that stands in the way of a team's productivity. This can literally be anything, from a team member who isn't pulling his or her weight to an uncomfortably warm team room. But if it's keeping the team from working at optimal efficiency, it's an impediment.

Luckily, Scrum dedicates an entire role to the resolution of these impediments: the ScrumMaster. The ScrumMaster works in a variety of capacities, such as helping the Product Owner prepare the backlog or radiating Scrum artifacts, but the primary responsibility of a ScrumMaster is to remove scrum impediments and facilitate a highly performing team. To help the ScrumMaster achieve this, the team is responsible for communicating what barriers are impeding their progress. This occurs each day in the daily Scrum, when team members report on their accomplishments for the past 24 hours, goals for the next 24 hours, and what scrum impediments stand in their way. This systematized feedback loop ensures that a ScrumMaster always knows what is keeping the team from success and work to remove them."

Estimations: storypoints vs hours

Refactor Your Mind » complexity

Another good posting of Tick Tonoli regarding the reoccuring topic of estimating by using abstract storypoints vs hours. I rarely managed to get the point across, maybe his explanation works better:

"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…"

Affinity Estimation-when there are a lot of stories to be estimated

I came across Rick Tonoli`s Blog and found a couple of very interesting articles. Still working my way through his postings, i'll praise him later in a separate article after covering his and other opinions on the topic of "affinity estimation". I didnt apply it myself, but it does sound like a good approach to get a high level estimation done without wasting too much time.

He is refering to Kane Mar's blog who in return references to Jukka Lindström who posted his comment here. I would love to test it as it sounds very intuitive. A might be more suitable for a pretty senior team, but then again, what isn't...

Here is Kane Mar's comment on it:
"We started by reading out each Story to the entire team. Lowell then asked us to arrange the stories horizontally on a wall in order of size, without talking. We placed the largest stories on the left and the smallest stories on the right. This only took a few minutes. We were then given a final opportunity to make adjustments to the ordering, again without talking.
 
...
Finally, “Affinity Estimating” helps make estimating a positive experience rather than a confrontational one. The next time you have a need to estimate a large number of User Stories, consider trying “Affinity Estimating."

Sounds like it could also be an interesting tool for team(member)s that struggle to speak their mind or or have problems with confrontations. Ball-parking new projects should/could be simpler as well.

You can find a more detailed description about how it works here.

Dealing with Conflict Avoidance Teams

Agile Blog: Role of Scrum Master - Dealing with Conflict Avoidance Teams

Have you come across teams where only a few speak and the rest listen ?

Have you seen any of your team members not sharing their thoughts or participating well during Scrum meetings, retrospectives or other activities ?

Have you come across any team where there is no conflict ?

Silent Teams
The teams where you don't see conflict, I would call them as "Silent teams" for the sake of this article are silent in speech, but not really silent in their mind. The people in this teams are like any other people but all their questions, frustrations, arguments everything is going only in their mind. They never speak up or discuss things in front of a group, especially if their ideas conflict with others. But there are chances that they go and share their frustrations with some one closer to them in the team during the cafe breaks or with any other close friend.