Calling Developers!
We are reenergizing our code contribution process! Learn More

What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

I read this and I wanted immediately to share it:

Options
Chemaclass
Chemaclass Tech Lead Spryker Solution Partner Posts: 213 🧑🏻‍🚀 - Cadet
in Knowledge Sharing

I read this and I wanted immediately to share it: https://twitter.com/allenholub/status/1525133067408576514

It’s a mistake to think that you need to accurately predict the amount of work you can do in a Sprint. The world will not end if you get it wrong. Too little work? Pull something else. Too much, push it back. “Committing” to finishing X stories is just dysfunction (& not Scrum).

What do you think?

Comments

  • USZ0XG6SK
    USZ0XG6SK Posts: 111 🧑🏻‍🚀 - Cadet
    Options

    I would say that whole estimations and commitment are there to help business and make planing more reliable. When it comes to development, i would agree that most of the time it is just an overhead.
    On the other hand you could argue that committing to X stories also increases developer responsibility for that what has to be implemented.

  • UKTSRTD5M
    UKTSRTD5M Posts: 77 🧑🏻‍🚀 - Cadet
    edited May 2022
    Options

    Allen & Scrum are not going to be friends anymore, are they? I do always argue in a similar direction: If your behaviour changes when the end of the sprint looms on the horizont - either because you start tu hurry or lift your feet - then I consider this "change in process" to be dysfunctional. For me, no dev should need "external pressure" to take responsibility for what has to be implemented. You should rather focus on optimizing your development process and stick with it. For me, the content of a sprint is more of an estimation. Typically (at least where I have seen Scrum mostly) it is an aggregation of smaller estimations / judgments. This may, and probably sometimes should, fail ; but still provides information valuable for business forecasts and predictions.
    But - as I am a developer? - I would always prefer higher output quality over more exact predictions ;)

Categories