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 effort and time required to arrive at an accurate number in days/hours for a story weighs against the benefits 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 .
Additionally:
if we have an estimate in days:
- I see the “illusion of control” or the “pretend to be in control” phenomen
and
- Developers tend to follow the “Parkinsons’s law”
“Work expands so as to fill the time available for its completion.”
Great paper from ThoughtWorks
http://www.thoughtworks-studios.com/sites/default/files/resource/twebook-perspectives-estimation_1.pdf
Organigram of Svenska Handelsbanken
Do you know the difference between a desirement and a requirement? via @ElegantCoder
Great article from David about “evolutionary architecture” and a nice example about it from the Microsoft Word ribbon.
David explains desirements and requirements as:
A desirement is a non-compiled request for software to change. Examples include specification documents, Team Foundation Server Work Items, index cards, and hope expressed with Microsoft Word.
Everyone can state a desirement and throw it on the bottom of the wishlist.
The interesting part is when a desirement gets closer to be a requirement (bubbles up) and the team discusses about the details and writes acceptance tests with the business to confirm them.
A requirement, on the other hand, is an automated test proving desired behavior exists in software. Requirements (tests) must pass before software may ship.
This leads to creating a ATDD Ready Backlog, which is a great way to make sure you have “always releasable software”.
Full article from David Starr:
http://visualstudiomagazine.com/articles/2013/01/07/leveling-up-agile-requirements.aspx
Are story points an excuse for teams not being able to estimate correctly in days/hours? 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
http://www.thoughtworks-studios.com/sites/default/files/resource/twebook-perspectives-estimation_1.pdf
when I fix a bug without testing
thecodinglove:
/* by jazzy */
Love this one!
Especially the T-Shirt!
what the client see when I open a terminal in front of him
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
http://agilemanagement.net/index.php/Blog/extending_the_five_core_practices_of_kanban/
Visualizing work at the Boeing 787 battery system team??
Why a Short Feedback Cycle is a Good Thing
Inside Portable Class Libraries
Big Code @ Google
- Google has a single code repository
Completely open to all of the 10000 developers
- All systems are released independently
- Release cycles randing from a week to a month
- Everything is built from HEAD without any binary releases
- Repository receives several thousand changes per day with spikes of 20+ changes per minute
from Gojko Adzic
http://gojko.net/2009/12/07/improving-testing-practices-at-google/
Remove humans from your process, they slow you down
TFS vNext Feature Request: Fail build if CodeCoverage dropped over 1 day
If testing is hard, blame your code before the test
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
Great read!!
Full article
http://martinfowler.com/articles/agileFluency.html
RSS feed