281–290 of 326 posts
usually means there's hidden complexity i haven't found yet. i estimate until the subtasks are small enough (like 4h chunks), otherwise its all just feeling based numbers.
Earlier quoted context omitted.
It could be a niche quote in an art history book, but it could hardly be qualified as a saying. I asked around since my first comment and not a single person knew about it.
It's so memorable, probably why it stick in my memory: how can you have a canvas without a wall? The wall is the canvas. Yet the wall simultaneously constrains the canvas, thus allowing it to become the canvas, to become worthy of a canvas. This French idiom says so much without saying practically anything.
As you say, it's not immediately clear what is meant.
Earlier quoted context omitted.
I worked on a product that was built around planning an estimation with ranged estimates (2-4h, 1-3d, etc) 2-12d conveys a very different story than 6-8d. Are the ranges precise? Nope, but they're useful in conveying uncertainty, which is something that gets dropped in any system that collapses estimates to a single point. That said, people tend to just collapse ranges, so I guess we all lose in the end.
> 2-12d conveys a very different story than 6-8d. In agile, 6-8d is considered totally reasonable variance, while 2-12d simply isn't permitted. If that's the level of uncertainty -- i.e. people simply can't decide on points -- you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing once you have a more accurate estimate. You would never just blindly d…
That's just too slow for business in my experience though. Rightly or wrongly, they want it now, not in a couple of sprints.
So what we do is we put both the investigation and the implementation in the same sprint, use the top of the range for the implementation, and re-evaluate things mid-sprint once the investigation is done. Of course this messes up predictability and agile people don't like it, but they don't have better ideas either on how to handle it.
Not sure if we're not enough agile or too agile for scrum.
Here's my (somewhat tongue-in-cheek) rubric: - If it's an internal project (like migrating from one vendor to another, with no user impact) then it takes as long as I can convince my boss it is reasonable to take. - If it's a project with user impact (like adding a new feature) then it takes as long as the estimated ROI remains positive. - If it's a project that requires coordination with external parties (like a cli…
Not a single mention of planning poker and story points? They're not perfect (nothing is), but they're actually pretty good. Every task has to be completable within a sprint. If it's not, you break it down until you have a part that you expect is. Everyone has to unanimously agree on how many points a particular story (task) is worth. The process of coming to unanimous agreement is the difficult part, and where the r…
My most productive team did no time estimates at all (short of very very rough project estimates i.e. "yeah I'll work on this project for at least the next quarter then we'll see"), and instead of spending endless time in planning meetings determining how complex a task was, we instead spent that time just doing the thing.
I agree it's best if working in isolation, but if you need to synchronise then estimations make sense.
If you need 3 months to implement something, and another team 1 week, and both need to be ready at the same time; then if you actually know those estimations the second team can wait until then and do something immediately useful in between.
Earlier quoted context omitted.
It's so memorable, probably why it stick in my memory: how can you have a canvas without a wall? The wall is the canvas. Yet the wall simultaneously constrains the canvas, thus allowing it to become the canvas, to become worthy of a canvas. This French idiom says so much without saying practically anything.
Coming back at this with a fresh mind, whoever said it could also have meant that every painting should be displayed: it requires a wall to hang on . As you say, it's not immediately clear what is meant.
Earlier quoted context omitted.
The problem I have is, conceptually a task always looks easy, but then as your coding, you hit several problems that are not simple to overcome - in fact, lot of times these issues turn into almost insolvable problems that blow out any time estimates ;(
It really depends. Anyone doing meaningful work will have hard time giving estimates. But churning up the next CRUD application with now special requirements can have no unknown variables. The question of course remains, why would anyone want to waste their time reinventing a spreadsheet.
I hope this is tongue in cheek, right? If not, here are some reasons:
1) spreadsheets embed "functions" via macros and macros are often flagged as malicious. Just combining native functions can get pretty complex.
2) in a spreadsheet, everybody sees the input, which is not always ideal
3) data types are controlled by users for the entire column or sheet, which can mess up formulas
I could probably think of additional reasons.
Earlier quoted context omitted.
There’s also something more concrete about asking “Can you get it done by end of tomorrow? What does that require?” I prefer it over estimating which feels more like asking the length of a piece of string.
The problem I have is, conceptually a task always looks easy, but then as your coding, you hit several problems that are not simple to overcome - in fact, lot of times these issues turn into almost insolvable problems that blow out any time estimates ;(
How do you know if your estimate is good? Would you rather bet on your estimate or on hitting one of 8 numbers on a 10-number roulette wheel? If you prefer one of the bets, adjust your estimates. If you're indifferent between the bets, the estimates accurately reflect your beliefs.
(The roulette wheel is from the book, How to Measure Anything by Hubbard. Confidence interval estimates are from LiquidPlanner, https://web.archive.org/web/20120508001704/http://www.liquid...)
Is it going to take more than two hours? Is it going to take more than two days? Is it going to take more than two weeks? Is it going to take more than two months? Is it going to take more than two years? If you can answer these questions, you can estimate using a confidence interval. If the estimate is too wide, break it down into smaller chunks, and re-estimate. If you can't break it down further, decide whether it…
What if the project involves trying one approach for a week, then assessing whether that approach still looks viable vs moving onto a different approach? This happens a lot with challenging projects, you basically just keep trying different things until one works.
On the high end, could it take more than 2 years? 1 year? 6 months? Stop when you are 80% confident that it won't take longer than some period.
So your estimate might be between two weeks and six months. Is that an acceptable estimate for the "buyer"? If not, is it worth expending effort to narrow the estimate?
Earlier quoted context omitted.
Funny, I've never been on a team that did . Otherwise, it would be impossible to have 20-point stories done in a 10-business-day sprint! Under the usual assumption that a single person is responsible for the whole story. For the teams I've been on, a point has usually been more like a third of a day or half a day, i.e. 2-3 hours of uninterrupted concentration, and the 1/2 point card is used rarely. Sounds like you've…
Yeah we had half-point stories. Never remember getting as high as 20. I think we topped out at about 13 and those were usually split if they could be. It's been years since I did planning poker, sort of surprised to hear that it's still in use.
Why? It's not like it was some fad that didn't work. When things work, organizations tend to stick with them.