Are story points an excuse for teams not being able to estimate correctly in days/hours? via @anand003
I get this asked quite often as well.
Q: Are story points an excuse for teams not being able to estimate correctly in days/hours?
A: The eﬀort and time required to arrive at an accurate number in days/hours for a story weighs against the beneﬁts of estimating as such. Moreover estimating in days/hours puts undue pressure on the team to deliver within those number of days, leading to the team unable to reach a sustainable pace, and possibly burning out .
if we have an estimate in days:
- I see the “illusion of control” or the “pretend to be in control” phenomen
- Developers tend to follow the “Parkinsons’s law”
“Work expands so as to fill the time available for its completion.”
Great paper from ThoughtWorks
How do we know if the team is getting better at estimation when it is estimating in points? via @anand003
This is something I get asked a lot in my current project.
Q: How do we know if the team is getting better at estimation when it is estimating in points?
It is a popular belief that if the team were to estimate in ideal days, then it would be much easier to track if the estimation is accurate, by checking the actual days elapsed on a story and the progress against it. This is however counterproductive as the team spends hours to estimate few stories to arrive at the magic number of days before being pressurized to deliver on that magic number.
When a team is relatively sizing stories in points, a trend slowly starts emerging where similarly sized stories start showing similar time to implement them. If there is a bad estimate, then that bubbles up automatically as an exception.
Great interview with Anand Vishwanath in this PDF from ThoughtWorks
The “Kanban Method” becoming more Agile by getting 2 important practices: TeamLeaderShip and Feedback Loops
A fellow trainer pointed me to this post from David Anderson: “EXTENDING THE FIVE CORE PRACTICES OF KANBAN”
As I’ve identified in presentations and key note speeches I gave in 2010, 2011 and earlier this year, the biggest oversight is leadership. Small acts of leadership from any member of the team need to happen regularly. It is these acts of leadership that make change happen.
So the 6th practice is: Leadership - give permission for ideas and encourage process innovation from any and all team members.
Sounds like building a team ;-)
There is also a need for explicit feedback loops. The Kanban book identifies these at two levels:
- the daily standup meeting at the team and individual contributor level
- and the operations review at the organization and inter-team or across services level
So the 7th practice is: Implement Organizational Feedback using Quantitative Measures of Demand and Capability
Sounds like having short feedback loops is a good thing
Visualizing work at the Boeing 787 battery system team??
Are you a 4* Team yet?
James Shore and Diana Larsen describe a model of Agile fluency including 4 stages of Agile Teams:
- Teams Create Business Value
- Teams Deliver on the Market’s Cadence
- Teams Optimize Their Value
- Teams Contribute to Optimizing the System
7 Obstacles to Enterprise Agility via @michaeldotjames
Great recap of the FBI sentinel project
Everybody loves to work within the “House of Scrum”
Gunther has some great visualizations of ”Lean” and “Scrum”.
He calls it the “The House of Scrum”: Standing on “Transparency” and 2 pillars: “Inspection” and “Adaptation” with the goal of the “Product”.
The House of Scrum is a great and energizing place where product development prospers from the combined, creative intelligence of people.
Who would not like to work there?
I really like the way how Gunther shows the compatibility between “Lean” and “Agile”
Lean —- Agile
- Respect for People —- Self-organizing Teams
- Kaizen —- Inspect & Adapt, short feedback cycles
- Prevent/Eliminate Waste —- No unused specs, architecture or infrastructure
- Pull inventory (Kanban) —- Information Radiators
- Built-in Quality —- Definition of Done, Engineering standards
- Customer Value —- Active Business Collaboration (Product Owner)
- Optimizing the whole —- Whole Team Together (incl. stakeholders)
- Deliver Fast —- Timeboxed iterations with working Increments
- The manager-teacher —- the facilitating servant-leader
Video: Elisabeth Hendrickson Discusses Agile Testing
Geeks guide on leading teams - Patrick Kua Recap #gotoAar
“If i write something and it doesnt get used, i get angry”
The ultimate test for a tech lead:
Does the codebase look like it was written by a single person?
We need consistency in what we are doing
Dear Customer: The Truth About IT Projects
Great essay via Allan Kelly
I think it’s time we in the IT industry come clean about how we charge you, why our bills are sometimes a bit higher than you might expect, and why so many IT projects result in disappointment. The truth is that when we start an IT project, we don’t know how much time and effort it will take to complete. Consequently, we don’t know how much it will cost. This may not be a message you like to hear, particularly since you are absolutely certain you know what you want.
5 Lessons Learned from the FBI’s Sentinel Project
- Private sector expertise is valuable.
- Agile development gets things done.
- Commercial software plays an important role.
- Agile development is cheaper, too.
- Don’t deploy new software on old hardware.
Sentinel is “arguably the most important application at the FBI,” and agile development turned out to be the right way to complete it, Fulgham told me this week.
“You cannot be agile if your code sucks”
Do you think before you code? via @arialdomartini
Scrum and Development Skills