undefined | Better HN

0 pointsBrandonM5y ago0 comments

Everything I've read to this point seemed to describe sprints as chunking every task so that it takes no more than 1–2 weeks to complete (depending on the company's sprint length). I inferred that a dev would be expected to pick up and complete one of those task chunks each sprint. I have seen occasional references to tasks that last 2 sprints.

I was contrasting with that model, though it sounds like I might not be accurately characterizing sprints. We've had some features that have taken over a year to complete, such as a major rearchitecture. The (generally senior) dev assigned to that task has a lot of latitude to break it up according to their judgement, submit individual parts on their own timeline, etc., all while minimizing bookkeeping and coordination with others. As long as they're continuing to make forward progress according to an initially vague, sensible, iterative plan, we tend to leave our established devs to their own devices. For newer devs and where multiple devs are collaborating on a feature together, we encourage at least weekly check-ins.

0 comments

3 comments · 1 top-level

lmm5y ago· 2 in thread

Ah, sorry, so you're saying it would be normal for a dev to take several of these 4-week periods between delivering anything? You're right, that's not scrum; not delivering anything in a given sprint shouldn't be a big deal (just re-estimate the remainder), but yeah, consistently having sprints where you don't deliver anything would be a cause for concern, and would suggest you're not breaking down your tasks enough.

I definitely wouldn't want to work in a model where you're expected to just take as long as it takes. Integrating a branch that's been going for 6 months is a nightmare; even when it goes well it's immensely stressful. Reintegrating your work back into the rest of the system can easily feel like it's taking "the other 90% of the time" - or even be impossible, if someone else has changed the system in an incompatible way in the meantime. Even if you were regularly merging code changes to master, if you try to release 6 months of work when none of it's ever been deployed to production yet then there's always the sinking feeling that maybe it's all just going to break. Or worst of all, maybe it works perfectly the way you thought it was meant to, but you misunderstood the spec and so all your work is useless.

I'm a bit confused by you talking about an "iterative" plan, because I don't see how you can meaningfully iterate if you're not delivering changes regularly - indeed "iteration" often gets used to mean the same thing as "sprint".

BrandonMOP5y ago

We generally don't have 6-month old branches. We don't shy away from assigning big projects to devs, though. They iteratively collaborate with our Product team to carve out a v1, and then get to work. We throw out reliability on delivery dates of any one feature, believing that we achieve higher throughput with less coordination (we avoid dependencies between features as much as possible).

The assigned dev absolutely breaks the big feature into reasonably atomic pull requests, ideally no more than a few hundred lines but sometimes a few thousand. The critical difference, I think, is that none of that breaking up is super planned out, and it's certainly not formalized prior to development. The changes often trickle out over several releases. Collaborators may help advise on where to break things up, but ultimately it's up to the dev to use good judgement.

I agree that 6 months of unmerged development is absolutely a horrible situation that's best to avoid.

lmm5y ago

> We generally don't have 6-month old branches. We don't shy away from assigning big projects to devs, though. They iteratively collaborate with our Product team to carve out a v1, and then get to work. We throw out reliability on delivery dates of any one feature, believing that we achieve higher throughput with less coordination (we avoid dependencies between features as much as possible).

If your product priorities are stable for 6 months at a time, you're in a rare position. And I'd worry about knowledge sharing and maintainability if whole functional areas were being implemented by one person on their own. I agree with avoiding having two people working on the same area in parallel if at all possible, and there's certainly an overhead to not having the same person do a series of related tasks, but if we're planning to share maintenance responsibility for that area of the code (which is what being on the same team means) then I think spreading out the development work is worth the overhead. And fundamentally if no-one else on the team can understand Bob's architecture then better to find that out sooner rather than later.

> The critical difference, I think, is that none of that breaking up is super planned out, and it's certainly not formalized prior to development. The changes often trickle out over several releases. Collaborators may help advise on where to break things up, but ultimately it's up to the dev to use good judgement.

Scrum doesn't favour large amounts of up-front planning - ideally you don't plan beyond the end of the sprint - but you define the user-facing change you're trying to make, at least in enough detail to a) tell whether it's actually done or not b) estimate enough to let you prioritize. Even if your priorities are stable enough that you don't need to do the latter, I think I'd always want to define what I'm aiming for in each release ahead of time - otherwise it's just too easy to scope creep and end up with those 6 months of unmerged changes. And if that goal isn't something user-facing then you're kidding yourself, IME - it's just too easy to overengineer or overarchitect and produce a bunch of churn that doesn't actually achieve anything, unless you're constantly keeping in mind what this change is actually supposed to achieve.

j / k navigate · click thread line to collapse