Hacker News Reader

Comment by greyman | Hacker News Reader

For our dev team Scrum works fine, the key is to use it just as a framework, and not following every rule to the letter. For example:

- Obsession with points

We don't have that obsession, sometimes we even don't assign story points, just hour estimates

- Meeting extravaganza -

Again, for example remote people don't need to attend all meetings, sometimes we just clarify the work items outside the meetings.

- The sprint has its own backlog, which can be changed only in agreement with the team and the product owner.

We also don't have this... if I finished my tasks, I just move new item from backlog to sprint and work on it.

- Refactoring, reading code, researching a topic in detail are all seen as "not working on actual story points, which is what you are paid to do".

This has some truth to it... regarding research, we do this outside the Scrum.

View on HN

I'm a designer and my experience with small scrum teams has more or less been the same - a lot of the issues are handled by developers who are given some agency to self-manage and who are half-decent at doing so. I've only worked in one environment that was true scrum, and I don't know if it was the process or the organization — but it felt so overly boxed-in.

The last point has been the biggest one for me. Across multiple organizations working in the scrum process I've occasionally felt like just getting some time to talk to developers for future exploratory work is like pulling teeth because the scrum process relies so heavily on tangible tasks. I think that's a time management thing that has to be established with teams ahead of time — like "hey 80% of your week are these tasks, but you have 20% set aside for research/discussion'

One can do this 80%/20% split. Not sure if it's mentioned in some official guide or it developed through trial and error.

Usually the 20% is reserved for bug fixing tasks which can't be estimated and therefore can't be included in the Scrum framework.

One of my projects has a "technical backlog" which is actually just a Jira task with multiple subtasks which gets dragged from sprint to sprint. As you can imagine this doesn't work so great from a process/tool perspective, but it gets the job done (i.e. Major refactorings can be and have been performed).

The thing with Scrum is that a lot depends on the PO and SM. If they're open minded and experienced you can get something decent. If they're dogmatic and pray at the altar of Jira, prepare for suffering.

Using time instead of points breaks the whole concept of sprint-based estimation which Scrum tries so very hard to defend. Basically Scrum claims that software developers can't estimate based on time so it forces them to use an abstract number instead. Over time this would lead to being able to estimate a project in sprint-sized blocks.

This is why sprints have a fixed duration, the sprint backlog should not be changed, stories are awarded the full points or 0 during review, commitments to finish the sprint, etc.

Sounds like you are doing "scrum but" aka your own methodology.

However their article is criticizing pure unadulterated scrum.

The article is also criticizing their particular version of scrum. For example "collecting points" or obsessing about them is not unadulterated scrum; the word points or planning poker are not even mentioned in the scrum guide. Any good developer, scrum master or book on scrum will tell you that story points are not a performance metric and they are only to be used by the PO and just for planning ahead.

There is little to criticise about pure unadulterated Scrum because there is surprisingly little prescribed and what little there is they openly tell you that you can change it in the retrospective. The real problem is that management, agile coaches (and unfortunately sometimes also some developers) often want to religiously apply every little thing they ever read in a book and seemed like a good idea. I think that solutions to all the problems the author mentioned are possible without deviating significantly or at all from scrum -- should that be important for whatever reason. The only prerequisite is that everyone involved is open to change.

"I just move new item from backlog to sprint and work on it." - This breaks traditional scrum estimating.

Yes and No. Scrum estimating is done with 2 independent metrics: Velocity and Task Hourly Estimate.

Obviously adding something to the Spring is going to hide the fact that you fucked up at Spring Planning. However, as the author said, very few people actually care about task estimate. ( and often team don't even care about breaking stories into task at all, using story == task ) And in any case, unless you are using postits and manual tracking, any tool will just track the estimate alright for you, the information is there if you want to process it.

Velocity is supposed to change from sprint to sprint, getting better as you are better at assigning story point. You can lose SP when you fuck up a story, you can gain extra when you put additional stuff from the backlog. Velocity once more or less stable is supposed to give an idea of a release date.

However considering that you don't break down big stories and epic into smaller stories until you are about ready to implement them, the uncertainty on the release date is more like 6 months vs 2 years vs 10 years. Management make a big deal of it but really that's how you budget most of the time anyway: I need "3 FTE for 6 months or 3 FTE for the year, to be reevaluated at budget cycle per budget cycle".

Most of OP problem actually started really when Scrum Master became a job. I remember something like 10 years ago being all exited how Jira could make very precise report of velocity and estimate and my very experimented coach looked at me as if she had seen the Demon. Scrum is about keeping a supertanker on track in a tempest and those amazing reports gives the illusion of a nimble sport car racing on a track.

Reply on news.ycombinator.com