5

We are currently doing Scrum in a trading environment, our sprints are a week long, the problem is that due to Change requests from trading activity during the sprint it is impossible to have a sprint backlog that is protected. The sprint backlog often gets changed mid week leading to it becoming a waterfall timeboxed sprint.

I am now not sure if Scrum is the right approach but keen to set this project up so that it is run in an agile way, what would you recommend? Thanks

Improve this question
4
  • Do you have a Product Owner whose role it is to prioritise/defend the backlog?
    – JBRWilkinson
    Commented Mar 14, 2018 at 16:43
  • Yes, everything is a must have, that is the problem
    – bobo2000
    Commented Mar 14, 2018 at 19:16
  • Is it really? Or is your PO running on old habits, or has not fully embraced agile?
    – Vicki Laidler
    Commented Mar 15, 2018 at 3:22
  • 1
    If everything is important, nothing is. Sounds like your product owner could use some coaching. I share this 15 minute video with every PO I work with: youtube.com/watch?v=502ILHjX9EE
    – Dan Bowling
    Commented Mar 15, 2018 at 6:01

2 Answers 2

Reset to default
11

If your sprint is only one week already and even that is frequently interrupted by high-priority changes, you aren't running a project business where you implement planned features, you are running a reactive, support/helpdesk style team (that maybe once in a while is able to finish a planned feature if business is slow otherwise).

Scrum is indeed not the best option. Look into Kanban instead. It's similar in some regards, but a better fit if your team is reacting instead of acting.

Improve this answer
4
  • Thanks, yes that is what I thought, my only concern is capacity, how do I factor it in if use the Kanban approach?
    – bobo2000
    Commented Mar 14, 2018 at 19:17
  • 1
    @bobo2000 kanban doesn't eliminate your teams ability to estimate tasks. It simply removes the defined start/end times of a sprint. In order to measure you need to look into KPIs such as Lead Time and Cycle Time rather than Story Points. Have a look into Scrumban too
    – Liath
    Commented Mar 16, 2018 at 17:24
  • @Liath have you got any good reading material on Scrumban
    – bobo2000
    Commented Mar 17, 2018 at 18:57
  • @bobo2000 see for example this article or this whitepaper
    – barghest
    Commented Apr 3, 2018 at 13:22
2

Not enough information to make a clear recommendation:

  • In principle it's possible that your environment runs on a faster beat than a week. If your tasks are all a matter of hours then yes, you might be better served with something like Kanban.
  • Another way to look at it is that a Sprint should be terminated if its goal no longer makes sense. If the changes in the business situation have truly invalidated the course you've selected for your sprint then it should be terminated. However if this continues to happen then that again indicates that your environment is too short lived for Scrum to work.
  • Far more common however is the case that your stakeholders simply don't want to wait. With one week sprints I'd expect your stories to fall into the range of one to a few weeks in length most of the time. In such a scenario pushing such a story into development a few days early makes little difference in time to completion and is nothing more than a power demonstration. In this case it falls to the PO and the SM to put their foot down for the team.
Improve this answer
1
  • The environment is very reactive to change, so backlog is volatile
    – bobo2000
    Commented Mar 14, 2018 at 10:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.