5 ms·

Taking on a new development process in the middle of a project is much harder than starting on a new one. In particular, as you mentioned there's an issue of l

Taking on a new development process in the middle of a project is much harder than starting on a new one. In particular, as you mentioned there's an issue of legacy bugs. There's mounds of information available suggesting strategies for taking care of this, but ultimately you'll be in an unfortunate transition while you're still handling legacy bugs that makes it hard to move forward. Most of my experience with agile is in the XP flavors, where the mantra is no bugs. I know it's hard to believe, but I promise it's an achievable goal if the whole team single-mindedly works towards that goal. You're right, estimating is hard. The thing is, people are actually really good at relative estimation, it's absolute estimation that we completely suck at. That's the idea behind estimating in points: you free yourself from trying to think "how long will this take me?", which you'll inevitably get wrong, to "is this harder or easier than this other thing" which almost always is pretty easy to do.

jackmaney 12y ago
> The thing is, people are actually really good at relative estimation, it's absolute estimation that we completely suck at. That's the idea behind estimating in points: you free yourself from trying to think "how long will this take me?", which you'll inevitably get wrong, to "is this harder or easier than this other thing" which almost always is pretty easy to do. That sounds great on paper. However, every implementation of Agile that I've ever seen or heard of eventually translates points to time intervals ("How many points should this be?" "Well, a one day task is three points, so...").
- lostcolony 12y ago
  Well, then, to give you a piece of anecdotal evidence; my experience where I currently am is that we never talk about how long it'll take, unless it's so small and trivial we can say "Give me an hour and I should have a first pass in place". Even then we're not saying it's ~done~, just that we're familiar enough with the code that we can get some prototypal code in place in a time frame. When actually estimating tasks, it's purely point based, and then those can and do vary with how much time they actually eat up, but tend to average out just fine.
  - jackmaney 12y ago
    "When actually estimating tasks, it's purely point based" The problem is that project managers and other business units don't give two flying shits about points. They want to know when things will be done. PM: "So, how long will it take you to have that new logging system implemented?" Developer: "It's a five point feature." PM: "So....two days, then?" D: "Well, I dunno...it's five points." PM: "Two days it is!" [puts deadline of two days from now into JIRA]
    - lostcolony 12y ago
      'PM' - well, there's a problem. We don't have project managers. Product -owners-, yes. But you have a point; a lot of places try to 'be agile', as something the devs do, without also including management. As a number of others in this thread even indicate. Management has to also change, or else there's a mismatch in expectations. As a dev doing SCRUM, we report point totals, and allow the business unit to prioritize stories based on that, and based on the need for the feature. Point totals above 8 or so we try and break down into more stories. The only guarantee we give is that if we include it in a sprint, we will get it done in that sprint. We can estimate it at ~8 hours (~two days of a single dev's time; we build in slack, for meetings, context changes, dev tasks, and the unexpected), but we aren't guaranteeing that you'll have it in two days; it'll be the end of the sprint. Any more exact estimate is only for other devs, in case they're reliant on it being in place for something they're working on.
      - jackmaney 12y ago
        Fine, "product owner" or "scrum master" or "person who schedules meetings and fiddles with the JIRA board". Whatever. I don't care what piece of jargon you want to substitute in. Let me ask you this: why should any customer or business unit give a flying fuck about your "points"? Customers and business units should have a strong voice in prioritization of tasks, yes. However, in the process of prioritization, an estimate of time for the task--be it your estimation or theirs--will be a factor. If all you tell them is a number of points, then guess what? They'll back into their own time estimations from your points.
- couchand 12y ago
  You're right, eventually you have to convert points to some notion of time, if only so that you know how much work you can do in a sprint. The idea is that you make that conversion based on past observation, using a velocity estimate that represents the past performance of the team and takes into account who's on vacation this week. There also should be an open recognition that your actual velocity will vary somewhat between sprints. One goal is to reduce that variability by improving your estimation (with practice!), but you anticipate and prepare for the variability. That's why you have a backlog (in case you need more work) and why you develop units of work that are independent (in case you need to push one). For all these reasons it's a mistake to think of an equivalence at the level of tasks such as one day is three points or something like that.
  - jackmaney 12y ago
    In every implementation of agile that I've ever seen or encountered, something like this occurs: "Okay, this story for Feature X, how many points should we give it?" "Well, it'll probably take N days, so, let's say, M points." Eventually, for the sake of consistency, a rough translation between points and time intervals is established.
    - couchand 12y ago
      I've seen that happen, too, but I've also seen it work.
NDizzle 12y ago
Legacy bugs? What the hell are legacy bugs?! What about, you know, normal bugs. Normal, unforeseen problems that happen all the time that you can't account for. Do you just add 25% time to any project to cover for those? I'm not sure how that solves the issue when you have to slice everything up into tiny chunks, where a few chunks could contain all of the unknown unknowns. It's good to realize the known unknowns, but it's the other kind that will get you.
- couchand 12y ago
  Legacy bugs are those in the codebase from before the team started working with a test first, no bugs mantra. As I alluded to there are many approaches to this problem, but one that I like is more or less just what you suggest: set aside some amount of time every sprint to tackle the legacy codebase. The eventual goal is to bring it up to the newly accepted standard which requires tests, but realistically that will take a while. Live bugs provide a sort of direction to help facilitate updating the legacy codebase. Setting aside a set amount of time each sprint makes sure that the issues don't get swept aside. It's important to get to the point where fixing live bugs isn't impeding the development of new features, but until then it's simply pragmatic to set aside some amount of time to hedge against new issues, while also having the discipline to set one aside if it can wait until the next sprint. As an aside, some of the best patterns on the subject of dealing with legacy systems can be found in the later chapters of Domain Driven Design by Eric Evans, particularly chapter 14, Maintaining Model Integrity.

jackmaney 12y ago

> The thing is, people are actually really good at relative estimation, it's absolute estimation that we completely suck at. That's the idea behind estimating in points: you free yourself from trying to think "how long will this take me?", which you'll inevitably get wrong, to "is this harder or easier than this other thing" which almost always is pretty easy to do. That sounds great on paper. However, every implementation of Agile that I've ever seen or heard of eventually translates points to time intervals ("How many points should this be?" "Well, a one day task is three points, so...").

lostcolony 12y ago
Well, then, to give you a piece of anecdotal evidence; my experience where I currently am is that we never talk about how long it'll take, unless it's so small and trivial we can say "Give me an hour and I should have a first pass in place". Even then we're not saying it's ~done~, just that we're familiar enough with the code that we can get some prototypal code in place in a time frame. When actually estimating tasks, it's purely point based, and then those can and do vary with how much time they actually eat up, but tend to average out just fine.
- jackmaney 12y ago
  "When actually estimating tasks, it's purely point based" The problem is that project managers and other business units don't give two flying shits about points. They want to know when things will be done. PM: "So, how long will it take you to have that new logging system implemented?" Developer: "It's a five point feature." PM: "So....two days, then?" D: "Well, I dunno...it's five points." PM: "Two days it is!" [puts deadline of two days from now into JIRA]
  - lostcolony 12y ago
    'PM' - well, there's a problem. We don't have project managers. Product -owners-, yes. But you have a point; a lot of places try to 'be agile', as something the devs do, without also including management. As a number of others in this thread even indicate. Management has to also change, or else there's a mismatch in expectations. As a dev doing SCRUM, we report point totals, and allow the business unit to prioritize stories based on that, and based on the need for the feature. Point totals above 8 or so we try and break down into more stories. The only guarantee we give is that if we include it in a sprint, we will get it done in that sprint. We can estimate it at ~8 hours (~two days of a single dev's time; we build in slack, for meetings, context changes, dev tasks, and the unexpected), but we aren't guaranteeing that you'll have it in two days; it'll be the end of the sprint. Any more exact estimate is only for other devs, in case they're reliant on it being in place for something they're working on.
    - jackmaney 12y ago
      Fine, "product owner" or "scrum master" or "person who schedules meetings and fiddles with the JIRA board". Whatever. I don't care what piece of jargon you want to substitute in. Let me ask you this: why should any customer or business unit give a flying fuck about your "points"? Customers and business units should have a strong voice in prioritization of tasks, yes. However, in the process of prioritization, an estimate of time for the task--be it your estimation or theirs--will be a factor. If all you tell them is a number of points, then guess what? They'll back into their own time estimations from your points.
couchand 12y ago
You're right, eventually you have to convert points to some notion of time, if only so that you know how much work you can do in a sprint. The idea is that you make that conversion based on past observation, using a velocity estimate that represents the past performance of the team and takes into account who's on vacation this week. There also should be an open recognition that your actual velocity will vary somewhat between sprints. One goal is to reduce that variability by improving your estimation (with practice!), but you anticipate and prepare for the variability. That's why you have a backlog (in case you need more work) and why you develop units of work that are independent (in case you need to push one). For all these reasons it's a mistake to think of an equivalence at the level of tasks such as one day is three points or something like that.
- jackmaney 12y ago
  In every implementation of agile that I've ever seen or encountered, something like this occurs: "Okay, this story for Feature X, how many points should we give it?" "Well, it'll probably take N days, so, let's say, M points." Eventually, for the sake of consistency, a rough translation between points and time intervals is established.
  - couchand 12y ago
    I've seen that happen, too, but I've also seen it work.

NDizzle 12y ago

Legacy bugs? What the hell are legacy bugs?! What about, you know, normal bugs. Normal, unforeseen problems that happen all the time that you can't account for. Do you just add 25% time to any project to cover for those? I'm not sure how that solves the issue when you have to slice everything up into tiny chunks, where a few chunks could contain all of the unknown unknowns. It's good to realize the known unknowns, but it's the other kind that will get you.

couchand 12y ago
Legacy bugs are those in the codebase from before the team started working with a test first, no bugs mantra. As I alluded to there are many approaches to this problem, but one that I like is more or less just what you suggest: set aside some amount of time every sprint to tackle the legacy codebase. The eventual goal is to bring it up to the newly accepted standard which requires tests, but realistically that will take a while. Live bugs provide a sort of direction to help facilitate updating the legacy codebase. Setting aside a set amount of time each sprint makes sure that the issues don't get swept aside. It's important to get to the point where fixing live bugs isn't impeding the development of new features, but until then it's simply pragmatic to set aside some amount of time to hedge against new issues, while also having the discipline to set one aside if it can wait until the next sprint. As an aside, some of the best patterns on the subject of dealing with legacy systems can be found in the later chapters of Domain Driven Design by Eric Evans, particularly chapter 14, Maintaining Model Integrity.