0

Vote down!

On Iterative Sprint Cycles

First published on 2022-12-19

In the below discussion I assume that the reader is already familiar with the basic agile / XP concepts. To recap, work is divided into sprints, usually of 2-wk length. Each day there is a standup (you don't have to actually stand on your feet), some companies implement two: one in the morning, one before end of day. The standup consists of each team member saying what they worked on yesterday, what they are working on today, and whether they are blocked. The worklog consists of tickets (a bunch of tickets is called an epic - unless it's called a sprint), a ticket describing who is gonna do what, and when. Tickets go across "lanes", the typical lanes for me are: todo, doing done. But industry-wide the lanes are: in-planning, on-deck, in-progress, ready-to-test, in-test, ready-to-release, closed (done), closed (will-no-do).

I just wanna say that the "industry-standard" two-week sprint makes no sense to me. My sprints are 1-day long. At the beginning of the day, I look at the worklog and take what I think I can accomplish in the day. That's it!

And for planning purposes I take the comfortable month. Everyone knows what a month is, the calendar is already divided into these, and it's a long enough span in the sense that at the end of it you should be able to see notieable progress for the month. (I do not necessarily see noticeable progress after one day of work. If something is unreleased, at the end of the day it may continue being unreleased. In a month, however, you should see meaningful progress.)

If the argument is that two weeks is just the right amount of time to keep everyone focused, that's also not true. Or at least I haven't seen it. Everyone and everything is always late. Things take two months on average (what things?). Releases are comfortably weekly, and not biweekly! Then to argue you say, oh but you can start your sprint on week 1 and slot the work into the release on week 3, you personally don't need to push out code every week. And then I say, okay but then make the sprint weekly, not bi-weekly, since it reflects what we're accomplishing in a week. And then you say, no what happens is you spend a week on implementation, and the QA spends a week on testing. That's why it's a two-week sprint: dev and QA. And then I say okay but that still means the schedule is weekly, not bi-weekly. If I send some functionality to QA at the end of week 1, then I have to work on something on week 2, while QA is checking my work. And then you say oh then just take two such tasks for one sprint, if it only takes a week. And then I say, so anyway the two-week sprint length does not make any sense. tl;dr my sprints are daily. And the analytical summaries are monthly.

And there are some industry standards that I agree with. The consensus is, no deployments on Fridays. Because if something breaks, noone is there Saturday to fix it. The best day for deployment is Thursday. This way, it can be comfortably done without worrying about an early end of day; if it takes too long you have Friday to finish/rollback; if something goes wrong Friday is the day to rollback; and it's still sort of a week-end so the concept of the week is preserved. I worked in a team where the bright minds decided to have releases on Tuesdays.

I suppose the management decided that if they can push the release day two days in advance, it would be like saving two days for them. It made no sense. But noone raised any objections, I didn't have enough seniority, and this was implemented.

In a few weeks, I personally stopped knowing what a week was, anymore. I think the entire team lost this basic intuition. If I'm working on something on week 1 and it's QA'ed on week 2, when is it going out? Supposedly on Tuesday of week 3, but somehow it just never worked out that way. QA would need to sign off on it by Monday. Of course, QA was in Asia a full 1/2-day ahead of us. Each communication with them took a full day. To give them one full day of testing, I had to give the code to QA by Thursday. All of this sounds reasonable but in practice it didn't work. I lost the concept of something "being released this week", only next week. Something being released this week was already obsolete.

the article girl

Related Articles

Please log in to post a comment: