#productowner — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #productowner, aggregated by home.social.
-
In a Wizard of Oz MVP, you present what looks to the end user like a fully functional product. Behind the scenes, it's just people doing the work.
The most famous example is Zappos (originally Shoesite). Like any good Lean startup, they needed to test their riskiest assumption: would anyone buy shoes online? You can't test fit, feel, or quality through a screen. Rather than spend millions building a fulfillment center, founder Tony Hsieh put up a website that sold shoes, then fulfilled orders manually by buying them at local stores.
Airbnb did something similar: the founders visited early hosts' homes, took professional photos, and listed them on the site themselves. When a guest booked, the founders handled the details in the background. Both were testing the same riskiest assumption: is it safe to buy or rent over the internet?
Build a realistic front end, leave out the back end, and iterate quickly as you see how people actually use it. To the end user, it has to look real. Measure whatever you'd normally measure in a live product: does the user buy, rent, or take the key action?
Pros: cheap, cheerful. Cons: consistency is hard to maintain doing repetitive tasks manually, and it doesn't scale. If demand overwhelms you early, you may need to shut the door temporarily and build the real thing. Remember, you built throw-away code. Don't build on top of it.
Wizard of Oz is one of my favourite MVP techniques.
https://agilepainrelief.com/glossary/wizard-of-oz/?utm_source=mastodon&utm_campaign=archive-reshare
-
In a Wizard of Oz MVP, you present what looks to the end user like a fully functional product. Behind the scenes, it's just people doing the work.
The most famous example is Zappos (originally Shoesite). Like any good Lean startup, they needed to test their riskiest assumption: would anyone buy shoes online? You can't test fit, feel, or quality through a screen. Rather than spend millions building a fulfillment center, founder Tony Hsieh put up a website that sold shoes, then fulfilled orders manually by buying them at local stores.
Airbnb did something similar: the founders visited early hosts' homes, took professional photos, and listed them on the site themselves. When a guest booked, the founders handled the details in the background. Both were testing the same riskiest assumption: is it safe to buy or rent over the internet?
Build a realistic front end, leave out the back end, and iterate quickly as you see how people actually use it. To the end user, it has to look real. Measure whatever you'd normally measure in a live product: does the user buy, rent, or take the key action?
Pros: cheap, cheerful. Cons: consistency is hard to maintain doing repetitive tasks manually, and it doesn't scale. If demand overwhelms you early, you may need to shut the door temporarily and build the real thing. Remember, you built throw-away code. Don't build on top of it.
Wizard of Oz is one of my favourite MVP techniques.
https://agilepainrelief.com/glossary/wizard-of-oz/?utm_source=mastodon&utm_campaign=archive-reshare
-
In a Wizard of Oz MVP, you present what looks to the end user like a fully functional product. Behind the scenes, it's just people doing the work.
The most famous example is Zappos (originally Shoesite). Like any good Lean startup, they needed to test their riskiest assumption: would anyone buy shoes online? You can't test fit, feel, or quality through a screen. Rather than spend millions building a fulfillment center, founder Tony Hsieh put up a website that sold shoes, then fulfilled orders manually by buying them at local stores.
Airbnb did something similar: the founders visited early hosts' homes, took professional photos, and listed them on the site themselves. When a guest booked, the founders handled the details in the background. Both were testing the same riskiest assumption: is it safe to buy or rent over the internet?
Build a realistic front end, leave out the back end, and iterate quickly as you see how people actually use it. To the end user, it has to look real. Measure whatever you'd normally measure in a live product: does the user buy, rent, or take the key action?
Pros: cheap, cheerful. Cons: consistency is hard to maintain doing repetitive tasks manually, and it doesn't scale. If demand overwhelms you early, you may need to shut the door temporarily and build the real thing. Remember, you built throw-away code. Don't build on top of it.
Wizard of Oz is one of my favourite MVP techniques.
https://agilepainrelief.com/glossary/wizard-of-oz/?utm_source=mastodon&utm_campaign=archive-reshare
-
In a Wizard of Oz MVP, you present what looks to the end user like a fully functional product. Behind the scenes, it's just people doing the work.
The most famous example is Zappos (originally Shoesite). Like any good Lean startup, they needed to test their riskiest assumption: would anyone buy shoes online? You can't test fit, feel, or quality through a screen. Rather than spend millions building a fulfillment center, founder Tony Hsieh put up a website that sold shoes, then fulfilled orders manually by buying them at local stores.
Airbnb did something similar: the founders visited early hosts' homes, took professional photos, and listed them on the site themselves. When a guest booked, the founders handled the details in the background. Both were testing the same riskiest assumption: is it safe to buy or rent over the internet?
Build a realistic front end, leave out the back end, and iterate quickly as you see how people actually use it. To the end user, it has to look real. Measure whatever you'd normally measure in a live product: does the user buy, rent, or take the key action?
Pros: cheap, cheerful. Cons: consistency is hard to maintain doing repetitive tasks manually, and it doesn't scale. If demand overwhelms you early, you may need to shut the door temporarily and build the real thing. Remember, you built throw-away code. Don't build on top of it.
Wizard of Oz is one of my favourite MVP techniques.
https://agilepainrelief.com/glossary/wizard-of-oz/?utm_source=mastodon&utm_campaign=archive-reshare
-
In a Wizard of Oz MVP, you present what looks to the end user like a fully functional product. Behind the scenes, it's just people doing the work.
The most famous example is Zappos (originally Shoesite). Like any good Lean startup, they needed to test their riskiest assumption: would anyone buy shoes online? You can't test fit, feel, or quality through a screen. Rather than spend millions building a fulfillment center, founder Tony Hsieh put up a website that sold shoes, then fulfilled orders manually by buying them at local stores.
Airbnb did something similar: the founders visited early hosts' homes, took professional photos, and listed them on the site themselves. When a guest booked, the founders handled the details in the background. Both were testing the same riskiest assumption: is it safe to buy or rent over the internet?
Build a realistic front end, leave out the back end, and iterate quickly as you see how people actually use it. To the end user, it has to look real. Measure whatever you'd normally measure in a live product: does the user buy, rent, or take the key action?
Pros: cheap, cheerful. Cons: consistency is hard to maintain doing repetitive tasks manually, and it doesn't scale. If demand overwhelms you early, you may need to shut the door temporarily and build the real thing. Remember, you built throw-away code. Don't build on top of it.
Wizard of Oz is one of my favourite MVP techniques.
https://agilepainrelief.com/glossary/wizard-of-oz/?utm_source=mastodon&utm_campaign=archive-reshare
-
A Scrum by Example teaching story, set in our fictional World's Smallest Online Bookstore.
About a third of the way down the Product Backlog there's a Story: "As Julia (a Real Estate Agent and frequent book buyer), I want to buy a gift card to thank a fantastic recent client." Estimated at 20, so the team agrees it needs to be split.
As the Scrum Team discusses the Story, they ask Product Owner Paula several clarifying questions. How will the recipient redeem the gift card? Already covered in a later story, also estimated at 20. Printable or electronic? Electronic for now. Fancy graphics and messaging? Nice to have, not essential for v1. Refillable or one-time use? Undecided.
Seeing that refillable gift cards cost 8 Story Points, Paula says, "That's expensive for the value I get," and pushes it down in priority. She also notices the combined cost of the $10 gift card Story and the alternate-denominations Story is 18 Points, quite large. She asks if it would be cheaper to allow any amount. The Team comes back with an estimate of 8: still more complex than the basic Story, but far less than 18.
All of this leads Paula to realize that being able to use a gift card is as important as buying one.
The leading cause of poor Sprint Planning, and therefore crappy Sprints, is team members not understanding the User Stories they're working on. Refinement exists to make sure the Product Backlog is clear and understood by everyone before the Sprint, not just to make it look good.
Scrum by Example is a narrative-style blog series designed to help people think through real problems on a Scrum team, especially the human ones.
-
A Scrum by Example teaching story, set in our fictional World's Smallest Online Bookstore.
About a third of the way down the Product Backlog there's a Story: "As Julia (a Real Estate Agent and frequent book buyer), I want to buy a gift card to thank a fantastic recent client." Estimated at 20, so the team agrees it needs to be split.
As the Scrum Team discusses the Story, they ask Product Owner Paula several clarifying questions. How will the recipient redeem the gift card? Already covered in a later story, also estimated at 20. Printable or electronic? Electronic for now. Fancy graphics and messaging? Nice to have, not essential for v1. Refillable or one-time use? Undecided.
Seeing that refillable gift cards cost 8 Story Points, Paula says, "That's expensive for the value I get," and pushes it down in priority. She also notices the combined cost of the $10 gift card Story and the alternate-denominations Story is 18 Points, quite large. She asks if it would be cheaper to allow any amount. The Team comes back with an estimate of 8: still more complex than the basic Story, but far less than 18.
All of this leads Paula to realize that being able to use a gift card is as important as buying one.
The leading cause of poor Sprint Planning, and therefore crappy Sprints, is team members not understanding the User Stories they're working on. Refinement exists to make sure the Product Backlog is clear and understood by everyone before the Sprint, not just to make it look good.
Scrum by Example is a narrative-style blog series designed to help people think through real problems on a Scrum team, especially the human ones.
-
A Scrum by Example teaching story, set in our fictional World's Smallest Online Bookstore.
About a third of the way down the Product Backlog there's a Story: "As Julia (a Real Estate Agent and frequent book buyer), I want to buy a gift card to thank a fantastic recent client." Estimated at 20, so the team agrees it needs to be split.
As the Scrum Team discusses the Story, they ask Product Owner Paula several clarifying questions. How will the recipient redeem the gift card? Already covered in a later story, also estimated at 20. Printable or electronic? Electronic for now. Fancy graphics and messaging? Nice to have, not essential for v1. Refillable or one-time use? Undecided.
Seeing that refillable gift cards cost 8 Story Points, Paula says, "That's expensive for the value I get," and pushes it down in priority. She also notices the combined cost of the $10 gift card Story and the alternate-denominations Story is 18 Points, quite large. She asks if it would be cheaper to allow any amount. The Team comes back with an estimate of 8: still more complex than the basic Story, but far less than 18.
All of this leads Paula to realize that being able to use a gift card is as important as buying one.
The leading cause of poor Sprint Planning, and therefore crappy Sprints, is team members not understanding the User Stories they're working on. Refinement exists to make sure the Product Backlog is clear and understood by everyone before the Sprint, not just to make it look good.
Scrum by Example is a narrative-style blog series designed to help people think through real problems on a Scrum team, especially the human ones.
-
A Scrum by Example teaching story, set in our fictional World's Smallest Online Bookstore.
About a third of the way down the Product Backlog there's a Story: "As Julia (a Real Estate Agent and frequent book buyer), I want to buy a gift card to thank a fantastic recent client." Estimated at 20, so the team agrees it needs to be split.
As the Scrum Team discusses the Story, they ask Product Owner Paula several clarifying questions. How will the recipient redeem the gift card? Already covered in a later story, also estimated at 20. Printable or electronic? Electronic for now. Fancy graphics and messaging? Nice to have, not essential for v1. Refillable or one-time use? Undecided.
Seeing that refillable gift cards cost 8 Story Points, Paula says, "That's expensive for the value I get," and pushes it down in priority. She also notices the combined cost of the $10 gift card Story and the alternate-denominations Story is 18 Points, quite large. She asks if it would be cheaper to allow any amount. The Team comes back with an estimate of 8: still more complex than the basic Story, but far less than 18.
All of this leads Paula to realize that being able to use a gift card is as important as buying one.
The leading cause of poor Sprint Planning, and therefore crappy Sprints, is team members not understanding the User Stories they're working on. Refinement exists to make sure the Product Backlog is clear and understood by everyone before the Sprint, not just to make it look good.
Scrum by Example is a narrative-style blog series designed to help people think through real problems on a Scrum team, especially the human ones.
-
A Scrum by Example teaching story, set in our fictional World's Smallest Online Bookstore.
About a third of the way down the Product Backlog there's a Story: "As Julia (a Real Estate Agent and frequent book buyer), I want to buy a gift card to thank a fantastic recent client." Estimated at 20, so the team agrees it needs to be split.
As the Scrum Team discusses the Story, they ask Product Owner Paula several clarifying questions. How will the recipient redeem the gift card? Already covered in a later story, also estimated at 20. Printable or electronic? Electronic for now. Fancy graphics and messaging? Nice to have, not essential for v1. Refillable or one-time use? Undecided.
Seeing that refillable gift cards cost 8 Story Points, Paula says, "That's expensive for the value I get," and pushes it down in priority. She also notices the combined cost of the $10 gift card Story and the alternate-denominations Story is 18 Points, quite large. She asks if it would be cheaper to allow any amount. The Team comes back with an estimate of 8: still more complex than the basic Story, but far less than 18.
All of this leads Paula to realize that being able to use a gift card is as important as buying one.
The leading cause of poor Sprint Planning, and therefore crappy Sprints, is team members not understanding the User Stories they're working on. Refinement exists to make sure the Product Backlog is clear and understood by everyone before the Sprint, not just to make it look good.
Scrum by Example is a narrative-style blog series designed to help people think through real problems on a Scrum team, especially the human ones.
-
Ich hatte dem Kunden in mehreren Workshops erklärt, warum wir agil arbeiten: schnelles Feedback, kleine Schritte, nur das bauen was er wirklich braucht.
Im Meeting danach fragte er, wann das ganze Projekt fertig ist.
Damals dachte ich: schlecht erklärt, nochmal ran. Das war falsch.
Er wird an einem Termin gemessen, nicht an meiner Methode. Ein weiterer Workshop hätte daran nichts geändert.
https://no-bullshit-agile.de/nba18-den-kunden-mitnehmen.html?mtm_campaign=mastodon
-
Ich hatte dem Kunden in mehreren Workshops erklärt, warum wir agil arbeiten: schnelles Feedback, kleine Schritte, nur das bauen was er wirklich braucht.
Im Meeting danach fragte er, wann das ganze Projekt fertig ist.
Damals dachte ich: schlecht erklärt, nochmal ran. Das war falsch.
Er wird an einem Termin gemessen, nicht an meiner Methode. Ein weiterer Workshop hätte daran nichts geändert.
https://no-bullshit-agile.de/nba18-den-kunden-mitnehmen.html?mtm_campaign=mastodon
-
Ich hatte dem Kunden in mehreren Workshops erklärt, warum wir agil arbeiten: schnelles Feedback, kleine Schritte, nur das bauen was er wirklich braucht.
Im Meeting danach fragte er, wann das ganze Projekt fertig ist.
Damals dachte ich: schlecht erklärt, nochmal ran. Das war falsch.
Er wird an einem Termin gemessen, nicht an meiner Methode. Ein weiterer Workshop hätte daran nichts geändert.
https://no-bullshit-agile.de/nba18-den-kunden-mitnehmen.html?mtm_campaign=mastodon
-
Ich hatte dem Kunden in mehreren Workshops erklärt, warum wir agil arbeiten: schnelles Feedback, kleine Schritte, nur das bauen was er wirklich braucht.
Im Meeting danach fragte er, wann das ganze Projekt fertig ist.
Damals dachte ich: schlecht erklärt, nochmal ran. Das war falsch.
Er wird an einem Termin gemessen, nicht an meiner Methode. Ein weiterer Workshop hätte daran nichts geändert.
https://no-bullshit-agile.de/nba18-den-kunden-mitnehmen.html?mtm_campaign=mastodon
-
Ich hatte dem Kunden in mehreren Workshops erklärt, warum wir agil arbeiten: schnelles Feedback, kleine Schritte, nur das bauen was er wirklich braucht.
Im Meeting danach fragte er, wann das ganze Projekt fertig ist.
Damals dachte ich: schlecht erklärt, nochmal ran. Das war falsch.
Er wird an einem Termin gemessen, nicht an meiner Methode. Ein weiterer Workshop hätte daran nichts geändert.
https://no-bullshit-agile.de/nba18-den-kunden-mitnehmen.html?mtm_campaign=mastodon
-
I think the Scrum Guide is wrong about the Product Owner and the Daily Scrum.
The Guide says neither the ScrumMaster nor Product Owner are required to attend. But does that mean that they shouldn't attend? The key sentence is: "If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers."
The Product Owner is accountable for maximizing the value of the product. So if their job is to help maximize value for the team, should they attend in their role as the PO? It seems simple. If they can help increase value, they should attend. When do they increase value? Most of the time.
When should they not attend? If they've not yet learned to balance their authority with the rules of the Scrum game. If they're acting as an order taker for stakeholders. When there's a risk of micro-management. When team members may not feel comfortable sharing information with them.
All of the cases where they shouldn't attend are cases where they're not playing their role well.
-
I think the Scrum Guide is wrong about the Product Owner and the Daily Scrum.
The Guide says neither the ScrumMaster nor Product Owner are required to attend. But does that mean that they shouldn't attend? The key sentence is: "If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers."
The Product Owner is accountable for maximizing the value of the product. So if their job is to help maximize value for the team, should they attend in their role as the PO? It seems simple. If they can help increase value, they should attend. When do they increase value? Most of the time.
When should they not attend? If they've not yet learned to balance their authority with the rules of the Scrum game. If they're acting as an order taker for stakeholders. When there's a risk of micro-management. When team members may not feel comfortable sharing information with them.
All of the cases where they shouldn't attend are cases where they're not playing their role well.
-
I think the Scrum Guide is wrong about the Product Owner and the Daily Scrum.
The Guide says neither the ScrumMaster nor Product Owner are required to attend. But does that mean that they shouldn't attend? The key sentence is: "If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers."
The Product Owner is accountable for maximizing the value of the product. So if their job is to help maximize value for the team, should they attend in their role as the PO? It seems simple. If they can help increase value, they should attend. When do they increase value? Most of the time.
When should they not attend? If they've not yet learned to balance their authority with the rules of the Scrum game. If they're acting as an order taker for stakeholders. When there's a risk of micro-management. When team members may not feel comfortable sharing information with them.
All of the cases where they shouldn't attend are cases where they're not playing their role well.
-
I think the Scrum Guide is wrong about the Product Owner and the Daily Scrum.
The Guide says neither the ScrumMaster nor Product Owner are required to attend. But does that mean that they shouldn't attend? The key sentence is: "If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers."
The Product Owner is accountable for maximizing the value of the product. So if their job is to help maximize value for the team, should they attend in their role as the PO? It seems simple. If they can help increase value, they should attend. When do they increase value? Most of the time.
When should they not attend? If they've not yet learned to balance their authority with the rules of the Scrum game. If they're acting as an order taker for stakeholders. When there's a risk of micro-management. When team members may not feel comfortable sharing information with them.
All of the cases where they shouldn't attend are cases where they're not playing their role well.
-
I think the Scrum Guide is wrong about the Product Owner and the Daily Scrum.
The Guide says neither the ScrumMaster nor Product Owner are required to attend. But does that mean that they shouldn't attend? The key sentence is: "If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers."
The Product Owner is accountable for maximizing the value of the product. So if their job is to help maximize value for the team, should they attend in their role as the PO? It seems simple. If they can help increase value, they should attend. When do they increase value? Most of the time.
When should they not attend? If they've not yet learned to balance their authority with the rules of the Scrum game. If they're acting as an order taker for stakeholders. When there's a risk of micro-management. When team members may not feel comfortable sharing information with them.
All of the cases where they shouldn't attend are cases where they're not playing their role well.
-
#Agile #Kanban #ProductOwner #Tech
Hello
Has anyone ever combined the roles of Project Manager + Technical Product Owner on a Kanban maintenance project? 🤔💡
What are the pitfalls to avoid ? Good practices ?
How do you manage prioritization between bugs, improvements and technical tasks ?
Do you have any tips to avoid overloading or role conflicts ?
Thanks in advance for your feedback 🙏😊 -
#Agile #Kanban #ProductOwner #Tech
Hello
Has anyone ever combined the roles of Project Manager + Technical Product Owner on a Kanban maintenance project? 🤔💡
What are the pitfalls to avoid ? Good practices ?
How do you manage prioritization between bugs, improvements and technical tasks ?
Do you have any tips to avoid overloading or role conflicts ?
Thanks in advance for your feedback 🙏😊 -
#Agile #Kanban #ProductOwner #Tech
Hello
Has anyone ever combined the roles of Project Manager + Technical Product Owner on a Kanban maintenance project? 🤔💡
What are the pitfalls to avoid ? Good practices ?
How do you manage prioritization between bugs, improvements and technical tasks ?
Do you have any tips to avoid overloading or role conflicts ?
Thanks in advance for your feedback 🙏😊 -
#Agile #Kanban #ProductOwner #Tech
Hello
Has anyone ever combined the roles of Project Manager + Technical Product Owner on a Kanban maintenance project? 🤔💡
What are the pitfalls to avoid ? Good practices ?
How do you manage prioritization between bugs, improvements and technical tasks ?
Do you have any tips to avoid overloading or role conflicts ?
Thanks in advance for your feedback 🙏😊 -
#Agile #Kanban #ProductOwner #Tech
Hello
Has anyone ever combined the roles of Project Manager + Technical Product Owner on a Kanban maintenance project? 🤔💡
What are the pitfalls to avoid ? Good practices ?
How do you manage prioritization between bugs, improvements and technical tasks ?
Do you have any tips to avoid overloading or role conflicts ?
Thanks in advance for your feedback 🙏😊 -
Bei der Kanban-Zertifizierung sagte der Referent so nebenbei: „Genau genommen bist du kein PO. Das ist der Kunde."
Fünf Jahre hatte ich die Rolle. Der Satz sitzt bis heute.
Wenn euer PO auf „warum bauen wir das?" keine Antwort hat, liegt das selten an ihm. Produktziel, Budget, Markt sitzen woanders. Er sortiert und übersetzt.
Was der Scrum Guide da verlangt:
https://no-bullshit-agile.de/nba20-product-owner-kann-nur-der-kunde-sein.html?mtm_campaign=mastodon -
Bei der Kanban-Zertifizierung sagte der Referent so nebenbei: „Genau genommen bist du kein PO. Das ist der Kunde."
Fünf Jahre hatte ich die Rolle. Der Satz sitzt bis heute.
Wenn euer PO auf „warum bauen wir das?" keine Antwort hat, liegt das selten an ihm. Produktziel, Budget, Markt sitzen woanders. Er sortiert und übersetzt.
Was der Scrum Guide da verlangt:
https://no-bullshit-agile.de/nba20-product-owner-kann-nur-der-kunde-sein.html?mtm_campaign=mastodon -
Bei der Kanban-Zertifizierung sagte der Referent so nebenbei: „Genau genommen bist du kein PO. Das ist der Kunde."
Fünf Jahre hatte ich die Rolle. Der Satz sitzt bis heute.
Wenn euer PO auf „warum bauen wir das?" keine Antwort hat, liegt das selten an ihm. Produktziel, Budget, Markt sitzen woanders. Er sortiert und übersetzt.
Was der Scrum Guide da verlangt:
https://no-bullshit-agile.de/nba20-product-owner-kann-nur-der-kunde-sein.html?mtm_campaign=mastodon -
Bei der Kanban-Zertifizierung sagte der Referent so nebenbei: „Genau genommen bist du kein PO. Das ist der Kunde."
Fünf Jahre hatte ich die Rolle. Der Satz sitzt bis heute.
Wenn euer PO auf „warum bauen wir das?" keine Antwort hat, liegt das selten an ihm. Produktziel, Budget, Markt sitzen woanders. Er sortiert und übersetzt.
Was der Scrum Guide da verlangt:
https://no-bullshit-agile.de/nba20-product-owner-kann-nur-der-kunde-sein.html?mtm_campaign=mastodon -
Bei der Kanban-Zertifizierung sagte der Referent so nebenbei: „Genau genommen bist du kein PO. Das ist der Kunde."
Fünf Jahre hatte ich die Rolle. Der Satz sitzt bis heute.
Wenn euer PO auf „warum bauen wir das?" keine Antwort hat, liegt das selten an ihm. Produktziel, Budget, Markt sitzen woanders. Er sortiert und übersetzt.
Was der Scrum Guide da verlangt:
https://no-bullshit-agile.de/nba20-product-owner-kann-nur-der-kunde-sein.html?mtm_campaign=mastodon -
🧮 Thought experiment: 100-item Product Backlog, team clears 7 per Sprint with zero defects (impossible, but stay with it). An item added at the bottom waits 14.5 Sprints, 28 weeks, before anyone touches it. By then priorities have shifted and it's often no longer relevant.
The fix: stop letting stakeholders ambush the PO one request at a time. Every 6-8 weeks, review what shipped and what's in flight before discussing what's next.
How long would an item added today actually wait?
-
🧮 Thought experiment: 100-item Product Backlog, team clears 7 per Sprint with zero defects (impossible, but stay with it). An item added at the bottom waits 14.5 Sprints, 28 weeks, before anyone touches it. By then priorities have shifted and it's often no longer relevant.
The fix: stop letting stakeholders ambush the PO one request at a time. Every 6-8 weeks, review what shipped and what's in flight before discussing what's next.
How long would an item added today actually wait?
-
🧮 Thought experiment: 100-item Product Backlog, team clears 7 per Sprint with zero defects (impossible, but stay with it). An item added at the bottom waits 14.5 Sprints, 28 weeks, before anyone touches it. By then priorities have shifted and it's often no longer relevant.
The fix: stop letting stakeholders ambush the PO one request at a time. Every 6-8 weeks, review what shipped and what's in flight before discussing what's next.
How long would an item added today actually wait?
-
🧮 Thought experiment: 100-item Product Backlog, team clears 7 per Sprint with zero defects (impossible, but stay with it). An item added at the bottom waits 14.5 Sprints, 28 weeks, before anyone touches it. By then priorities have shifted and it's often no longer relevant.
The fix: stop letting stakeholders ambush the PO one request at a time. Every 6-8 weeks, review what shipped and what's in flight before discussing what's next.
How long would an item added today actually wait?
-
🧮 Thought experiment: 100-item Product Backlog, team clears 7 per Sprint with zero defects (impossible, but stay with it). An item added at the bottom waits 14.5 Sprints, 28 weeks, before anyone touches it. By then priorities have shifted and it's often no longer relevant.
The fix: stop letting stakeholders ambush the PO one request at a time. Every 6-8 weeks, review what shipped and what's in flight before discussing what's next.
How long would an item added today actually wait?
-
Das ideale agile Projekt hat für mich als jemand der Projekte für Kunden macht, nichts mit Scrum zu tun. Auch nichts mit dem Team.
Es hängt an jemandem, der gar nicht im Team sitzt. Antwortet der Kunde nicht, nennt kein Ziel und schaut sich nichts an, dann hilft dir kein Framework und kein User Story Mapping. Du lieferst, und niemand sagt dir, ob es stimmt.
Das ist der Teil, den du nicht selbst reparieren kannst.
https://no-bullshit-agile.de/nba57-ideales-agiles-projekt.html?mtm_campaign=mastodon
-
Das ideale agile Projekt hat für mich als jemand der Projekte für Kunden macht, nichts mit Scrum zu tun. Auch nichts mit dem Team.
Es hängt an jemandem, der gar nicht im Team sitzt. Antwortet der Kunde nicht, nennt kein Ziel und schaut sich nichts an, dann hilft dir kein Framework und kein User Story Mapping. Du lieferst, und niemand sagt dir, ob es stimmt.
Das ist der Teil, den du nicht selbst reparieren kannst.
https://no-bullshit-agile.de/nba57-ideales-agiles-projekt.html?mtm_campaign=mastodon
-
Das ideale agile Projekt hat für mich als jemand der Projekte für Kunden macht, nichts mit Scrum zu tun. Auch nichts mit dem Team.
Es hängt an jemandem, der gar nicht im Team sitzt. Antwortet der Kunde nicht, nennt kein Ziel und schaut sich nichts an, dann hilft dir kein Framework und kein User Story Mapping. Du lieferst, und niemand sagt dir, ob es stimmt.
Das ist der Teil, den du nicht selbst reparieren kannst.
https://no-bullshit-agile.de/nba57-ideales-agiles-projekt.html?mtm_campaign=mastodon
-
Das ideale agile Projekt hat für mich als jemand der Projekte für Kunden macht, nichts mit Scrum zu tun. Auch nichts mit dem Team.
Es hängt an jemandem, der gar nicht im Team sitzt. Antwortet der Kunde nicht, nennt kein Ziel und schaut sich nichts an, dann hilft dir kein Framework und kein User Story Mapping. Du lieferst, und niemand sagt dir, ob es stimmt.
Das ist der Teil, den du nicht selbst reparieren kannst.
https://no-bullshit-agile.de/nba57-ideales-agiles-projekt.html?mtm_campaign=mastodon
-
Das ideale agile Projekt hat für mich als jemand der Projekte für Kunden macht, nichts mit Scrum zu tun. Auch nichts mit dem Team.
Es hängt an jemandem, der gar nicht im Team sitzt. Antwortet der Kunde nicht, nennt kein Ziel und schaut sich nichts an, dann hilft dir kein Framework und kein User Story Mapping. Du lieferst, und niemand sagt dir, ob es stimmt.
Das ist der Teil, den du nicht selbst reparieren kannst.
https://no-bullshit-agile.de/nba57-ideales-agiles-projekt.html?mtm_campaign=mastodon
-
Mythos: „Als PO sollst du während des Sprints nicht mit den Devs sprechen."
Der Gedanke ist nicht böse. Devs sollen in Ruhe arbeiten. Nur verschwindet die Rückfrage dadurch nicht, sie wartet. Aus zwei Minuten werden zwei Wochen, und im Review heißt es: konnten wir nicht fertigstellen, es waren Fragen offen.
Individuen und Interaktionen über Prozesse. Steht im Manifest an Stelle eins.
https://no-bullshit-agile.de/nba41-die-devs-bitte-nicht-ansprechen.html?mtm_campaign=mastodon
-
Mythos: „Als PO sollst du während des Sprints nicht mit den Devs sprechen."
Der Gedanke ist nicht böse. Devs sollen in Ruhe arbeiten. Nur verschwindet die Rückfrage dadurch nicht, sie wartet. Aus zwei Minuten werden zwei Wochen, und im Review heißt es: konnten wir nicht fertigstellen, es waren Fragen offen.
Individuen und Interaktionen über Prozesse. Steht im Manifest an Stelle eins.
https://no-bullshit-agile.de/nba41-die-devs-bitte-nicht-ansprechen.html?mtm_campaign=mastodon
-
Mythos: „Als PO sollst du während des Sprints nicht mit den Devs sprechen."
Der Gedanke ist nicht böse. Devs sollen in Ruhe arbeiten. Nur verschwindet die Rückfrage dadurch nicht, sie wartet. Aus zwei Minuten werden zwei Wochen, und im Review heißt es: konnten wir nicht fertigstellen, es waren Fragen offen.
Individuen und Interaktionen über Prozesse. Steht im Manifest an Stelle eins.
https://no-bullshit-agile.de/nba41-die-devs-bitte-nicht-ansprechen.html?mtm_campaign=mastodon
-
Mythos: „Als PO sollst du während des Sprints nicht mit den Devs sprechen."
Der Gedanke ist nicht böse. Devs sollen in Ruhe arbeiten. Nur verschwindet die Rückfrage dadurch nicht, sie wartet. Aus zwei Minuten werden zwei Wochen, und im Review heißt es: konnten wir nicht fertigstellen, es waren Fragen offen.
Individuen und Interaktionen über Prozesse. Steht im Manifest an Stelle eins.
https://no-bullshit-agile.de/nba41-die-devs-bitte-nicht-ansprechen.html?mtm_campaign=mastodon
-
Mythos: „Als PO sollst du während des Sprints nicht mit den Devs sprechen."
Der Gedanke ist nicht böse. Devs sollen in Ruhe arbeiten. Nur verschwindet die Rückfrage dadurch nicht, sie wartet. Aus zwei Minuten werden zwei Wochen, und im Review heißt es: konnten wir nicht fertigstellen, es waren Fragen offen.
Individuen und Interaktionen über Prozesse. Steht im Manifest an Stelle eins.
https://no-bullshit-agile.de/nba41-die-devs-bitte-nicht-ansprechen.html?mtm_campaign=mastodon
-
🧪 More and more products are clearly built with GenAI: features that don't fit together, some solving no real problem.
Even when building is cheap, building the wrong thing is still expensive.
Before GenAI the bottleneck was Quality Assurance. GenAI doesn't fix that, it just pushes more code upstream of the same bottleneck. Classic Theory of Constraints.
GenAI speeds up the mechanics of Discovery, which means we need to spend MORE time thinking, not less. Ask each week: what did we learn that changed our plan? If nothing, it's theatre.
-
🧪 More and more products are clearly built with GenAI: features that don't fit together, some solving no real problem.
Even when building is cheap, building the wrong thing is still expensive.
Before GenAI the bottleneck was Quality Assurance. GenAI doesn't fix that, it just pushes more code upstream of the same bottleneck. Classic Theory of Constraints.
GenAI speeds up the mechanics of Discovery, which means we need to spend MORE time thinking, not less. Ask each week: what did we learn that changed our plan? If nothing, it's theatre.
-
🧪 More and more products are clearly built with GenAI: features that don't fit together, some solving no real problem.
Even when building is cheap, building the wrong thing is still expensive.
Before GenAI the bottleneck was Quality Assurance. GenAI doesn't fix that, it just pushes more code upstream of the same bottleneck. Classic Theory of Constraints.
GenAI speeds up the mechanics of Discovery, which means we need to spend MORE time thinking, not less. Ask each week: what did we learn that changed our plan? If nothing, it's theatre.
-
🧪 More and more products are clearly built with GenAI: features that don't fit together, some solving no real problem.
Even when building is cheap, building the wrong thing is still expensive.
Before GenAI the bottleneck was Quality Assurance. GenAI doesn't fix that, it just pushes more code upstream of the same bottleneck. Classic Theory of Constraints.
GenAI speeds up the mechanics of Discovery, which means we need to spend MORE time thinking, not less. Ask each week: what did we learn that changed our plan? If nothing, it's theatre.
-
🧪 More and more products are clearly built with GenAI: features that don't fit together, some solving no real problem.
Even when building is cheap, building the wrong thing is still expensive.
Before GenAI the bottleneck was Quality Assurance. GenAI doesn't fix that, it just pushes more code upstream of the same bottleneck. Classic Theory of Constraints.
GenAI speeds up the mechanics of Discovery, which means we need to spend MORE time thinking, not less. Ask each week: what did we learn that changed our plan? If nothing, it's theatre.