3 ms·

I'm not a management guru, so I might be off-base but Agile isn't about sprinting tasks. Tasks, broken up enough, are much smaller than a sprint. It's about hav

I'm not a management guru, so I might be off-base but Agile isn't about sprinting tasks. Tasks, broken up enough, are much smaller than a sprint. It's about having a deliverable at a certain short term goal post. You cut corners and smash half finished features together to reach that goal so that you have a product you can pivot around (the word "pivot" always makes me throw up a little - maybe... reassess the direction of the project?). With test driven development and continual integration tools you constantly have a deliverable, so there is no longer any reason to sprint. You can "pivot" or whatever at any point in time The real question is test driven development / continual-integration worth doing? CI isn't too controversial, but for TDD there is no clear answer and it really depends on the domain and what language you work in etc. etc.

lostcolony 10y ago
So the way I have always handled it - Product owners create stories. These are titled things like "As a (type of user), I want to be able to X". The point of the title is to determine who this actually benefits. Then, they attempt to define it with acceptance criteria. These are a list of "what does it mean to solve this need". Ideally, it implies a set of tasks, and gives a decent starting point for QA to start testing. This is stuff like "When the user clicks X, the system shall Y" and "Should the system fail to do Y, it will instead (failure mode), and (inform the user? Stay silent? Whatever). Sometimes the product owner needs help from the devs to determine this. The devs will then add tasks to the story. The story should be able to be completed in one sprint; the tasks are, indeed, much faster. They're tracked only insofar as to see progress towards the story's completion, but they're not nearly as important as the story itself. A story with half of its tasks complete is not done; the feature is not implemented, it's not ready to go out. When all the tasks are done, the story is handed off to QA to vet; at that point the story is done, and it can be shipped. The dev team is only ever committing to what can be done in a sprint. They should have an idea of how many story points they can handle in a sprint, such that they can work with the product owner to determine the stories they'll work on in that sprint. When the estimates start lining up with what is actually achieved (that is, the team has a velocity of, say, 40 story points per sprint. And they're completing 40 story points per sprint), the product owner can start planning around it. "We have four sprints until the business wants the next milestone. As such, I have assigned 160 points worth of stories to try to get in for that". And that's reasonable. And then, if anything emergent comes up, or new stories take priority (a 'pivot', if you will), the product owner knows they can't manage it; they either need to replace a currently existing story with that emergent/newly prioritized story, or, they need to slip the schedule. And that can actually work. It requires honesty, transparency, and a desire to actually get shit done, but it can work. The problem is oftentimes people or cultures value CYA, politics, and 'leadership' over getting shit done, and all of those make agile little more than a scapegoat for why everything is on fire. And it's only one way of being agile. Kanban, for instance, still has stories and tasks as described, and it still offers velocity, though measuring it slightly differently, but it isn't concerned about the sprint boundaries.
- optforfon 10y ago
  Thanks for the explanation - that really clarified things for me. The breakdown between story, task, sprint and milestone is very interesting and well thought out. Good estimate generation is the holy grail
  - ktRolster 10y ago
    Good estimate generation is the holy grail If estimating is what you want to learn, James Shore has some good posts on the topic: http://www.jamesshore.com/Blog/Agile-and-Predictability.html http://www.jamesshore.com/Blog/Agile-and-Predictability.html http://www.jamesshore.com/Agile-Book/estimating.html http://www.jamesshore.com/Agile-Book/estimating.html
    - optforfon 10y ago
      Well as a freelancer it's something I've sorta given up hope on being able to do. Thanks again for the information. Hopefully it'll give me some ideas.
- wsc981 10y ago
  What always annoyed me about Story Points is that it's a measure of complexity, not time. At least that's what Story Points are supposed to stand for. When you state that a team should know how many Story Points it can handle, it would make much more sense to see Story Points as some measure of time. If you've completed last few Sprints 38 to 42 Story Points, with 2 full-time devs, than one could state that a single developer on average can finish 20 Story Points in Sprint. And if a Sprint is 2 weeks (10 days), that would mean maybe 2 Story Points per day for each dev. Yet, in every business environment I've been in, the SCRUM fanatics always state that "No, story points are a measure of complexity". In practice, to me, this makes no sense. At least not if one wants to use historic Story Points to estimate how much work can be completed in the next Sprint.
  - lostcolony 10y ago
    I'm not that dogmatic. But complexity should loosely correspond to time, I would think. A deeply complex task is going to entail more work than a simple one. That said, there's a good reason to say it measures the complexity, and not the time. You want to keep distance between your estimates and time, or else the business people are likely to come to you and say "You said this will take 6 hours, so I expect it tomorrow". Nevermind that it requires another task to be done first, that it's blocked on getting something from another department, that you only ever committed to delivering it at the end of the sprint, and that you underestimated how long it would take anyway (but it doesn't matter because you overestimated something else so it comes out in the wash), -you- said it would only take 6 hours!
fuck_google 10y ago
Perhaps you work at Google? In other companies the definition of done usually covers more than just pushing shit to the CI server.

lostcolony 10y ago

So the way I have always handled it - Product owners create stories. These are titled things like "As a (type of user), I want to be able to X". The point of the title is to determine who this actually benefits. Then, they attempt to define it with acceptance criteria. These are a list of "what does it mean to solve this need". Ideally, it implies a set of tasks, and gives a decent starting point for QA to start testing. This is stuff like "When the user clicks X, the system shall Y" and "Should the system fail to do Y, it will instead (failure mode), and (inform the user? Stay silent? Whatever). Sometimes the product owner needs help from the devs to determine this. The devs will then add tasks to the story. The story should be able to be completed in one sprint; the tasks are, indeed, much faster. They're tracked only insofar as to see progress towards the story's completion, but they're not nearly as important as the story itself. A story with half of its tasks complete is not done; the feature is not implemented, it's not ready to go out. When all the tasks are done, the story is handed off to QA to vet; at that point the story is done, and it can be shipped. The dev team is only ever committing to what can be done in a sprint. They should have an idea of how many story points they can handle in a sprint, such that they can work with the product owner to determine the stories they'll work on in that sprint. When the estimates start lining up with what is actually achieved (that is, the team has a velocity of, say, 40 story points per sprint. And they're completing 40 story points per sprint), the product owner can start planning around it. "We have four sprints until the business wants the next milestone. As such, I have assigned 160 points worth of stories to try to get in for that". And that's reasonable. And then, if anything emergent comes up, or new stories take priority (a 'pivot', if you will), the product owner knows they can't manage it; they either need to replace a currently existing story with that emergent/newly prioritized story, or, they need to slip the schedule. And that can actually work. It requires honesty, transparency, and a desire to actually get shit done, but it can work. The problem is oftentimes people or cultures value CYA, politics, and 'leadership' over getting shit done, and all of those make agile little more than a scapegoat for why everything is on fire. And it's only one way of being agile. Kanban, for instance, still has stories and tasks as described, and it still offers velocity, though measuring it slightly differently, but it isn't concerned about the sprint boundaries.

optforfon 10y ago
Thanks for the explanation - that really clarified things for me. The breakdown between story, task, sprint and milestone is very interesting and well thought out. Good estimate generation is the holy grail
- ktRolster 10y ago
  Good estimate generation is the holy grail If estimating is what you want to learn, James Shore has some good posts on the topic: http://www.jamesshore.com/Blog/Agile-and-Predictability.html http://www.jamesshore.com/Blog/Agile-and-Predictability.html http://www.jamesshore.com/Agile-Book/estimating.html http://www.jamesshore.com/Agile-Book/estimating.html
  - optforfon 10y ago
    Well as a freelancer it's something I've sorta given up hope on being able to do. Thanks again for the information. Hopefully it'll give me some ideas.
wsc981 10y ago
What always annoyed me about Story Points is that it's a measure of complexity, not time. At least that's what Story Points are supposed to stand for. When you state that a team should know how many Story Points it can handle, it would make much more sense to see Story Points as some measure of time. If you've completed last few Sprints 38 to 42 Story Points, with 2 full-time devs, than one could state that a single developer on average can finish 20 Story Points in Sprint. And if a Sprint is 2 weeks (10 days), that would mean maybe 2 Story Points per day for each dev. Yet, in every business environment I've been in, the SCRUM fanatics always state that "No, story points are a measure of complexity". In practice, to me, this makes no sense. At least not if one wants to use historic Story Points to estimate how much work can be completed in the next Sprint.
- lostcolony 10y ago
  I'm not that dogmatic. But complexity should loosely correspond to time, I would think. A deeply complex task is going to entail more work than a simple one. That said, there's a good reason to say it measures the complexity, and not the time. You want to keep distance between your estimates and time, or else the business people are likely to come to you and say "You said this will take 6 hours, so I expect it tomorrow". Nevermind that it requires another task to be done first, that it's blocked on getting something from another department, that you only ever committed to delivering it at the end of the sprint, and that you underestimated how long it would take anyway (but it doesn't matter because you overestimated something else so it comes out in the wash), -you- said it would only take 6 hours!

fuck_google 10y ago

Perhaps you work at Google? In other companies the definition of done usually covers more than just pushing shit to the CI server.