IMO the biggest issue with backlogs is when you go into detail to early. There is nothing wrong with epics to outline the end result. But user stories created on too vague requirements, which will only form during development, are a risk. They may be never used oder are wrong and then not changed. We currently have a backlog nobody wants to touch because it would mean a big and lengthy discussion with the client which has expectations already and you get a bad feeling like „why change it now, if we anyway gonna change it again“ We most likely gonna archive user stories more than two sprints into the future.
I agree about the issues with the backlog, but I missed ( i was multitasking) what is the replacement? Where do you track things that need to be done, but not immediately?
Exciting presentation, indeed, but all attempts separate planning from doing are doomed, and this shaping thing is not different and not a silver bullet at all. The whole idea comes from the basecamp methodology I believe. And yes, enforcing natural constraints works. The initial pitch against the backlog fallacies was weak TBH. In the nutshell, Shape Up is just an extreme version of agile, limited to 3x biweekly iterations, no magic here. The eggs, side view.
I agree. More often than not I end up modifying the original idea, the API, the future as I develop, as I discover things. I talk to the team and we change course as we develop. To each their own I guess
All attempts to separate planning from doing are doomed? Is this just true in software or everywhere? Have we never planned anything in human history? I’m unable to decide if this is too insightful for my benighted state or the thought-stopping mantra of a True Believer
Learning the basics of programming, so the po can effectively communicate with developers? Too often po's say I don't understand what developers are talking about. The product is software, not a PowerPoint presentation.
Product owners help to guide shape up teams during their builds if they need it. Most of the time however, PO's are thinking about the next pitches to shape.
I am impressed by the analogy of the horse breaking its leg by stepping into a rabbit hole.
IMO the biggest issue with backlogs is when you go into detail to early. There is nothing wrong with epics to outline the end result. But user stories created on too vague requirements, which will only form during development, are a risk. They may be never used oder are wrong and then not changed.
We currently have a backlog nobody wants to touch because it would mean a big and lengthy discussion with the client which has expectations already and you get a bad feeling like „why change it now, if we anyway gonna change it again“
We most likely gonna archive user stories more than two sprints into the future.
Great summary of Shape Up, thanks!
I agree about the issues with the backlog, but I missed ( i was multitasking) what is the replacement? Where do you track things that need to be done, but not immediately?
The point is that you don't
Individuals keep track of their bets/ideas/pitches themselves privately, if they want.
Decentralised backlog
I personally favour a User Story Map for this. I believe it suits this problem really well.
Exciting presentation, indeed, but all attempts separate planning from doing are doomed, and this shaping thing is not different and not a silver bullet at all. The whole idea comes from the basecamp methodology I believe. And yes, enforcing natural constraints works. The initial pitch against the backlog fallacies was weak TBH. In the nutshell, Shape Up is just an extreme version of agile, limited to 3x biweekly iterations, no magic here. The eggs, side view.
I agree. More often than not I end up modifying the original idea, the API, the future as I develop, as I discover things. I talk to the team and we change course as we develop. To each their own I guess
All attempts to separate planning from doing are doomed? Is this just true in software or everywhere? Have we never planned anything in human history? I’m unable to decide if this is too insightful for my benighted state or the thought-stopping mantra of a True Believer
But.....but.....but....what will a product owner do?????
Learning the basics of programming, so the po can effectively communicate with developers? Too often po's say I don't understand what developers are talking about. The product is software, not a PowerPoint presentation.
Product owners help to guide shape up teams during their builds if they need it. Most of the time however, PO's are thinking about the next pitches to shape.
Place their bets and pitch. Everyone is involved here