
Ask HN: Does your team plan work in sprints/cycles? - kevsim
If so, what’s the primary value you derive from them?<p>If not, why not?<p>I’ve worked in companies where sprints worked fine and others where they became a source of frustration (largely I think due to overly ambitious sprint planning).<p>Disclosure - I’m one of the founders of a company making a new issue tracker [0] and how best to support teams that work in sprints&#x2F;cycles is something we care quite a lot about<p>0: https:&#x2F;&#x2F;Kitemaker.co
======
oldsklgdfth
My current employer promotes scrum/agile, so we have sprints with company-wide
sprint reviews.

We don't get much value from them because there is little sprint planning, and
2 days before the review there is a push to figure out what is "done" to
present.

I have worked on other teams that embraced the planning aspect better and it
was a source of reassurance that everyone was on the same page.

The primary value (when I was on a team that did it "right") was the common
context that was shared by all and represented in the kanban (literally,
sticky notes on the wall and some masking tape). There was transparency and
traceability. I'm not sure it made us more "efficiency" or "productive", but i
removed a lot of frustration of being in the dark about what the team is
doing.

~~~
kevsim
> There was transparency and traceability

That makes a lot of sense. Do you think you could have achieved the same thing
with regular sync ups or prioritization meetings or discussions without
worrying too much about what you'd get done the next X weeks?

~~~
oldsklgdfth
I think it's possible, as long as there is a central place with all this
information.

> without worrying too much about what you'd get done the next X weeks

We didn't worry too much about metrics or progress. We just had everything
going on in sticky notes on the wall. You could walk in, look at the wall and
get an idea of what's going on outside of what you are working on.

Personally, I like whiteboards and sticky notes(gives you an excuse to get up
and move around). But it can be jira, trac, a wiki, a textfile in the repo.

I like knowing what's going on around me and how things fit together. Others
like working in isolation and following requirements. In my experience,
understanding the origin of requirements and the context is important to the
dev process.

------
2rsf
I don't even remember when I last worked in a non sprints/cycles way (the year
started with 201x or even 200x).

But sprints does not necessarily equals cycles, and cycles does not
necessarily equals Scrum or Agile.

I totally agree with you stand that "overly ambitious sprint planning" is the
root of all evil, many teams forget that planning is not a construction plan
but more of a show of intents and you can see the stress level fluctuating
between the start and end of sprints.

Another big problem is task estimation, we know that we are bad at it but the
"process" forces us to estimate anyway. This in turn leads to more of the
above mentioned stress since we usually under estimate.

I found that many times usually Kanban, or ScrumBan works quite well and
mitigate some of the mentioned problems.

------
giantg2
We use sprints.

It's frustrating due to overambitious programs and management 'metricizing'
it.

