I’m going to read the article but first my two cents: you should refactor every story. Even if it’s just a small thing like moving a method to a new class. Even if it’s not related to the story but you just noticed it while navigating the code base.
If your team isn't delivering on weekly sprints something is wrong. Perhaps you are over committing. If you are resorting to two week springs to forgo the useless double hour loss of the sprint plan / follow up demo, then sure, I get it.
In any of the two above cases it sounds like you have a weak team on your hands. When you push to treat the subject like a marathon it makes the business people nervous.
When you are on an incremental weekly delivery cycle, and things are late, it is usually only late by one or two of those weekly cycles. BUT, If things are late on a "marathon cycle" they are usually late by a "marathon length".
You sort of have to keep in mind that there's a rather large reason that there was a push by the business people to force faster cycles. You and your team are expensive. Weekly or bi-weekly goals show your accounting department that they are receiving assets.
In my experience, I've never seen anything useful delivered in 1-week sprints. That pace generates a lot of activity and a lot of stuff that looks like work, but it's mostly just people planning stuff that can't be done in a week and having meetings about why it can't happen this week and most items being tossed out as blocked.
2-week sprints aren't a whole lot better. I could see maintenance and bug-fixing teams being workable at that pace, but new development projects I've seen have always been a total waste of time on that schedule. Yes, it does keep the business side of the company happy because they see a lot of activity and feel like real work must be happening. But the actual situation is that nothing is really happening--just very loudly and energetically.
My company uses a mix of 2 and 3 week sprints (not on the same teams). My team uses 3 week. I mostly agree with you. Many of our tasks are done well within the 3-week period, but some take more time, and 3 weeks seems to be a happy middle ground. We could probably do 2 week sprints, but our “miss rate” would go up a bit. And at the end of the day, our clients can’t absorb changes that fast anyways.
There are types of work where you may deliver nothing for months. I think the sprint idea mainly works for well understood tasks where there are no surprises. I often work on stuff where I can only report failure for weeks or months until it hopefully works.
Can you please elaborate somewhat on the nature of these projects? I’d like to understand what it is about the work that makes it difficult to get interim results.
For example I have worked on a way to launch a process in Windows with certain privileges from a service. It's a little unusual but important for the way our software works and right now the lack of this capability creates the need for a lot of clunky workarounds. Based on my reading of some Windows APIs I suspected we could make this work but it took 12 weeks to actually make it work. There was no guarantee of success either and there were no intermediate results.
Any kind of research into a novel solution will basically be failure until it is suddenly success. If you can see that success coming from very far away you're not doing novel work.
