6 ms·

The things I've taken from scrum and use at every team: - plan in 2 week chunks - estimate in points (relative size to something you've already done), emphasi

The things I've taken from scrum and use at every team: - plan in 2 week chunks - estimate in points (relative size to something you've already done), emphasis on consistent estimates for each dev. - make sure you define what 'done' means, and make sure it relates to what exactly you are trying to measure (Eg just coding effort, work till feature can ship?, etc). This is probably the most tricky bit. - capture total velocity every 2 weeks and eventually use the avg for future planning - review the entire process and modify things that take a lot of time for devs.

deleted 3y ago
[deleted]
bluGill 3y ago
I have long abandoned scrum for Kanban. I don't care about sprints, and getting things done by the end. Just give me (or since I'm the team leader now often I'm the one giving) the next thing to work on and when it is done I'll start the next. Nobody cares about what you got done this sprint, they care about what what got into the next release. Next release includes a lot of manual testing as despite a very great automated test program we constantly discover a lot of serious bugs in manual test that are difficult to automate. we gave up on points. All anyone cares about is days. Thus it is better to retro on the days estimate vs days to deliver and make adjustments on our end. Nobody cares about days for an individual story anyway - they want the days for the complete feature (or at least enough of the feature that we can ship it)
- tilwidnk 3y ago
  Agreed, Scrum is a death march. Kanban is the way.
  - shortlived 3y ago
    Yeah, you are doing it wrong if scrum is deadlines. I've worked with people who had to pull all nighters to get all sprint content done before the sprint closes. I'm using it more as a window to do some cheap analysis on our progress.
    - skydhash 3y ago
      They are always deadlines as long as the cycle is official. An informal status update can be done with the project management tool, a 1:1 meeting or a quick team meeting (in this order)
      - The_Colonel 3y ago
        My experience is very different. Sprint wasn't a deadline in any of the companies I've worked at.
        deleted 3y ago
        [deleted]
- nottorp 3y ago
  > despite a very great automated test program we constantly discover a lot of serious bugs in manual test that are difficult to automate +1 :) Yes, I could just upvote. But this deserves more emphasis than that.
jsploit 3y ago
> estimate in points (relative size to something you've already done), emphasis on consistent estimates for each dev. > capture total velocity every 2 weeks and eventually use the avg for future planning This aspect of scrum has never made sense to me. Planning with average velocity turns points into an obfuscated time estimate - why use points at all?
- steelframe 3y ago
  It's a psychological trick to counter our bias toward scheduling optimism.
xbar 3y ago
Sounds like an agile application of scrum.
ed_elliott_asc 3y ago
“Past performance is not a predictor of future success” Capacity planning only really works where you are creating the same thing over and over. Otherwise I’d suggest it is better to just bring work in and work on it (kanban basically)
SCdF 3y ago
> - capture total velocity every 2 weeks and eventually use the avg for future planning I have never got to this stage. Someone is added to the team. Someone leaves the team. New team members get more knowledge. Old team members get sick or take a lot of leave. The focus of what you're working on moves from one part of the code base to another. Every time you have to throw your velocity out the window because you're not the same team any more, and those metrics are for a different team that no longer exists. You could argue points are useful as a discussion point to make sure there isn't some massive piece of complexity hiding in something (everyone says 3 points, the quiet person who knows the most about it says 13), but even tshirt sizing covers that imo, and regardless after that you should just throw them away.
- shortlived 3y ago
  Yeah, it won't work without a stable team. And that may be okay in a true agile environment but I've always had a manager who wants some type of estimate/high level schedule. We do T-shirt sizes mapped to numbers, because recording effort in numbers lets you get an avg etc...

deleted 3y ago

[deleted]

bluGill 3y ago

I have long abandoned scrum for Kanban. I don't care about sprints, and getting things done by the end. Just give me (or since I'm the team leader now often I'm the one giving) the next thing to work on and when it is done I'll start the next. Nobody cares about what you got done this sprint, they care about what what got into the next release. Next release includes a lot of manual testing as despite a very great automated test program we constantly discover a lot of serious bugs in manual test that are difficult to automate. we gave up on points. All anyone cares about is days. Thus it is better to retro on the days estimate vs days to deliver and make adjustments on our end. Nobody cares about days for an individual story anyway - they want the days for the complete feature (or at least enough of the feature that we can ship it)

tilwidnk 3y ago
Agreed, Scrum is a death march. Kanban is the way.
- shortlived 3y ago
  Yeah, you are doing it wrong if scrum is deadlines. I've worked with people who had to pull all nighters to get all sprint content done before the sprint closes. I'm using it more as a window to do some cheap analysis on our progress.
  - skydhash 3y ago
    They are always deadlines as long as the cycle is official. An informal status update can be done with the project management tool, a 1:1 meeting or a quick team meeting (in this order)
    - The_Colonel 3y ago
      My experience is very different. Sprint wasn't a deadline in any of the companies I've worked at.
      - deleted 3y ago
        [deleted]
nottorp 3y ago
> despite a very great automated test program we constantly discover a lot of serious bugs in manual test that are difficult to automate +1 :) Yes, I could just upvote. But this deserves more emphasis than that.

jsploit 3y ago

> estimate in points (relative size to something you've already done), emphasis on consistent estimates for each dev. > capture total velocity every 2 weeks and eventually use the avg for future planning This aspect of scrum has never made sense to me. Planning with average velocity turns points into an obfuscated time estimate - why use points at all?

steelframe 3y ago
It's a psychological trick to counter our bias toward scheduling optimism.

xbar 3y ago

Sounds like an agile application of scrum.

ed_elliott_asc 3y ago

“Past performance is not a predictor of future success” Capacity planning only really works where you are creating the same thing over and over. Otherwise I’d suggest it is better to just bring work in and work on it (kanban basically)

SCdF 3y ago

> - capture total velocity every 2 weeks and eventually use the avg for future planning I have never got to this stage. Someone is added to the team. Someone leaves the team. New team members get more knowledge. Old team members get sick or take a lot of leave. The focus of what you're working on moves from one part of the code base to another. Every time you have to throw your velocity out the window because you're not the same team any more, and those metrics are for a different team that no longer exists. You could argue points are useful as a discussion point to make sure there isn't some massive piece of complexity hiding in something (everyone says 3 points, the quiet person who knows the most about it says 13), but even tshirt sizing covers that imo, and regardless after that you should just throw them away.

shortlived 3y ago
Yeah, it won't work without a stable team. And that may be okay in a true agile environment but I've always had a manager who wants some type of estimate/high level schedule. We do T-shirt sizes mapped to numbers, because recording effort in numbers lets you get an avg etc...