3 ms·

> Because we break it into unrealistically small steps and as soon as you finish one step you have to wait for the end of the sprint (2 weeks) and present it, t

> Because we break it into unrealistically small steps and as soon as you finish one step you have to wait for the end of the sprint (2 weeks) and present it, then groom/plan the next step. This isn't really how sprints are supposed to work. Seems like a misunderstanding of how to manage a backlog.

quickthrower2 9y ago
How is it supposed to work? You have a piece of work that takes about 12 weeks, for example. You have 2 week sprints. You need to break it down into chunks you can do inside 2 weeks. However estimating sucks. You might need 4 weeks for one of the chunks, or 4 hours. You find out once you start looking at the legacy code and find you need to refactor 10k lines of code, or just flick a bit. If it takes 4 hours, do you wait 2 weeks to do the next chunk or bring it forward. In the scrum guide [1] there is no mention about putting more stuff in mid-sprint, so I assume it is OK to do that. What if it takes too long? Roll it over to the next sprint. I guess in spite of Scrum you can continuously work on the 12 week feature, and make the right motions to keep the process happy. [1] http://www.scrumguides.org/scrum-guide.html http://www.scrumguides.org/scrum-guide.html
- quickthrower2 9y ago
  Add: I think the breaking up of the 12 weeks into chunks is a good practice so you can measure progress, and have discussions about removing bits if you blow up on time. However if 1 dev is doing this work they can do it on their own rhythm - maybe releasing 3 things in one week and nothing for 3 weeks. There is no need to synchronize with the team.
- tucaz 9y ago
  May I ask what could possibly take 12 weeks worth of work before having anything useful? The idea behind any agile method is exactly to fight that kind of mentality that says you can only have software done in a Big Bang approach where everything gets released all at once. If a piece of software needs 12 weeks to be done then there is something wrong with your software environment. There’s always a way to release something useful in 2 weeks or even less. Some people do daily releases. The catch here that might not be obvious unless you look for it is that what you release in 2 weeks doesn’t have to be complete. Just ready. If you are making a search engine of course you need more than 12 weeks, but in the first sprint you can release the component to tokenize strings, for example.
  - sheepmullet 9y ago
    > May I ask what could possibly take 12 weeks worth of work before having anything useful? 12 person weeks is a tiny amount of effort. > but in the first sprint you can release the component to tokenize strings, for example. Ah I see - You just have to redefine what useful means :P. If your customer needs a search engine then having a string tokenizer is not useful at all. You don't run a project this way to improve individual developer productivity. You run it this way to reduce infrastructure and project risk. Often using Scrum practices is a good tradeoff - the problem is the messaging. The truth is we are trading off developer productivity and growth in order to lower overall risk and make the software process more predictable.
  - chuck4932 9y ago
    My problem is not with releasing new code every 2 weeks. I am 100% in favour of that I try and keep my releases as small and as frequent as possible. My problem is with planning/grooming/reviewing/presenting every single 2 week release. I think it should be up to the developer to decide how often they release new code not the product manager or anybody else. Of course it is always better to release often and in small amounts but this is not always possible hence why it should be at the developer's discretion.
- tucaz 9y ago
  To address the estimate point I must say that there’s nothing in scrum preventing you from trying things before giving an estimate. Having a task specifically to do exploratory coding is, in fact, encouraged by extreme programming. Even after that if you find that you estimated completely wrong it’s no big deal. That’s what it is for. You need to find mistakes. I’m not saying this is the case but it seems that your particular implantation of scrum is very poorly done. Especially if your only resource is the scrum guide. The actual book written by Ken Schwaber mentions that you can add things to a sprint of work is completed before the end of the sprint. This is part of the process and just like in the previous case is also saying that your knowledge is lacking because you finished the work before you thought you would. Agile methods are tools to help improve the cadence and predictability of software delivery.
chuck4932 9y ago
But isn't it a rule in SCRUM that no new cards can be introduced in the middle of a sprint? And isn't it also a rule two co-dependent cards cannot be done in the same sprint? (i.e. if card B depends on card A being finished).

quickthrower2 9y ago

How is it supposed to work? You have a piece of work that takes about 12 weeks, for example. You have 2 week sprints. You need to break it down into chunks you can do inside 2 weeks. However estimating sucks. You might need 4 weeks for one of the chunks, or 4 hours. You find out once you start looking at the legacy code and find you need to refactor 10k lines of code, or just flick a bit. If it takes 4 hours, do you wait 2 weeks to do the next chunk or bring it forward. In the scrum guide [1] there is no mention about putting more stuff in mid-sprint, so I assume it is OK to do that. What if it takes too long? Roll it over to the next sprint. I guess in spite of Scrum you can continuously work on the 12 week feature, and make the right motions to keep the process happy. [1] http://www.scrumguides.org/scrum-guide.html http://www.scrumguides.org/scrum-guide.html

quickthrower2 9y ago
Add: I think the breaking up of the 12 weeks into chunks is a good practice so you can measure progress, and have discussions about removing bits if you blow up on time. However if 1 dev is doing this work they can do it on their own rhythm - maybe releasing 3 things in one week and nothing for 3 weeks. There is no need to synchronize with the team.
tucaz 9y ago
May I ask what could possibly take 12 weeks worth of work before having anything useful? The idea behind any agile method is exactly to fight that kind of mentality that says you can only have software done in a Big Bang approach where everything gets released all at once. If a piece of software needs 12 weeks to be done then there is something wrong with your software environment. There’s always a way to release something useful in 2 weeks or even less. Some people do daily releases. The catch here that might not be obvious unless you look for it is that what you release in 2 weeks doesn’t have to be complete. Just ready. If you are making a search engine of course you need more than 12 weeks, but in the first sprint you can release the component to tokenize strings, for example.
- sheepmullet 9y ago
  > May I ask what could possibly take 12 weeks worth of work before having anything useful? 12 person weeks is a tiny amount of effort. > but in the first sprint you can release the component to tokenize strings, for example. Ah I see - You just have to redefine what useful means :P. If your customer needs a search engine then having a string tokenizer is not useful at all. You don't run a project this way to improve individual developer productivity. You run it this way to reduce infrastructure and project risk. Often using Scrum practices is a good tradeoff - the problem is the messaging. The truth is we are trading off developer productivity and growth in order to lower overall risk and make the software process more predictable.
- chuck4932 9y ago
  My problem is not with releasing new code every 2 weeks. I am 100% in favour of that I try and keep my releases as small and as frequent as possible. My problem is with planning/grooming/reviewing/presenting every single 2 week release. I think it should be up to the developer to decide how often they release new code not the product manager or anybody else. Of course it is always better to release often and in small amounts but this is not always possible hence why it should be at the developer's discretion.
tucaz 9y ago
To address the estimate point I must say that there’s nothing in scrum preventing you from trying things before giving an estimate. Having a task specifically to do exploratory coding is, in fact, encouraged by extreme programming. Even after that if you find that you estimated completely wrong it’s no big deal. That’s what it is for. You need to find mistakes. I’m not saying this is the case but it seems that your particular implantation of scrum is very poorly done. Especially if your only resource is the scrum guide. The actual book written by Ken Schwaber mentions that you can add things to a sprint of work is completed before the end of the sprint. This is part of the process and just like in the previous case is also saying that your knowledge is lacking because you finished the work before you thought you would. Agile methods are tools to help improve the cadence and predictability of software delivery.

chuck4932 9y ago

But isn't it a rule in SCRUM that no new cards can be introduced in the middle of a sprint? And isn't it also a rule two co-dependent cards cannot be done in the same sprint? (i.e. if card B depends on card A being finished).