There are books, podcasts, talks, conferences and careers built on this topic!
When it comes to succinct guides there is what frameworks suggest and then there is what is advocated based on experience! This post is my musing on the latter.
It is not meant to take anything away from what Agile frameworks state instead is meant to compliment the view frameworks have of the role and its responsibilities, here’s what the Scrum guide states (I am a huge fan of the Scrum framework for it’s simplicity).
The super succinct version is; a Product Owner is a Pirate Captain! Outside the enterprise we known them as entrepreneurs, within an enterprise we have come to know them as intrapreneurs… or a slight twist to Tendayi Viki‘s words… A Pirate In the navy.
Scrum advocates our Scrum Master’s are the shield for the team, I have lived with that for many years… But for the past few I’ve been advocating a slightly different approach. Sure Scrum Masters are the shield, however if it comes to that our problems have already come too close! The Uruk-hai are already at the Gates of Hornburg! We need them dealt with further upstream! The defence of the team (including the Product owner and Scrum Master)… specially high performing teams I’ve worked with starts with the Product Owner! Continue reading →
‘I want to create a practical guide for product owners to facilitate them in writing acceptance criteria for user stories so that their output is of value to the scrum team’
You’ll find pages after pages describing what an acceptance criteria is and how to write a good one, what it should include or not, however this post takes a practical approach for Product Owners to follow. You’ll find post after post describing how product owners ought to use Gherkin script to develop/write an acceptance criteria, which in my opinion is not a practical approach, there are a few things wrong with that approach, a few come to mind right now:Continue reading →
User stories when developed and utilised correctly are the most powerful agile technique to capture product functionality, though writing user stories may seem easy, writing good stories is hard. Furthermore most of us get fixated and seldom go beyond the basics, and end up with visibly complete but useless user stories!
Components of a User Story evolve/grow both vertically (spawn more Epics) and horizontally (become more involved) – their state of completion changes during the product and sprint backlog’s lifecycle. In the deck below I explore individual components that make up a ‘complete’ and ‘ready for dev’ user story, it is based on personal successes and failures and is by its agile nature an incomplete deck! it will evolve and as it does I’ll keep you folks updated.
Lastly, If you got value from what I have shared please consider giving back by contributing to @BringPTP, you can follow, broadcast or donate: http://gofundme.com/bringptp. Peace Through Prosperity (PTP) improves the local/domestic environment for peace by nurturing prosperity in conflict affected geographies. PTP alleviates poverty, prevents radicalisation through empowering micro-entrepreneurs with knowledge, skills, ability and increasing their access to income and opportunities. PTP supports small businesses, owned/managed by vulnerable and marginalised individuals/groups in society. PTP is innovating program design and delivery by using Agile design and delivery frameworks to create and deliver low cost, immediate and lasting impact social development programs in ‘at risk’ communities.