It is the end of the year! 52 posts (actually a couple more because of days like today). I’ll probably end up writing another post later today, hence the 52A. A product manager who doesn't write specs/stories/tickets? That's blasphemy say some. That's incredible, say others.
I agree with the assessment that tickets and user stories are often abused. They are used as handoffs and to avoid building shared understanding among PMs, designers, developers and other members. In this sense, I think that a team where PMs don't have to write user stories as much as other "typical" teams is a positive sign at first.
But "placeholders for conversations" can also imply that we only need conversations and not stories. Sometimes details are lost and things are not acted upon, even if we talked about and agreed together.
I think the better way to think about user stories are like pictures. When you look at a picture, you recall the details that are not in that picture, but the picture serves a purpose. Sometimes you forget what's there if you never look at the pictures.
So details that we agree upon, acceptance criteria and shared understanding should be captured, preferably in the form of user stories. I think the collective efforts of building shared understanding naturally result in user stories, and so in a sense, "PM's don't need to write user stories" is still true. They don't "need" to write user stories, user stories naturally arise!
When you build something reasonably complex, having your shared understanding captured in ways that we can point at and discuss is pretty useful.
"A user story is supposed to be a placeholder for a conversation."-100%! The entire team, or all that are needed to deliver the story should have a hand in contributing to what goes on the ticket. I think there is still value to writing them. It gives the team a model of level of understanding, but if the team is not having those conversations, that is worrisome.
For years Ive been interpreting the Waterfall v's agile conversation and thinking the driving end point was elimination pert and gant charts (these being seen as the equivalent of waterfall - and a despised practice in the dark arts).
From within the post (worthwhile) the idea of story can include scenario planning and testing via intelligent use of classic project management tools. The strategic development of alternate story plots that are reconfigured to identify and navigate critical elements ahead of just doing it. This is not line by line prescription, that I could see a bureaucrat bent on micromanagement reveling in, the actual Waterfall diagnosis that causes screams and howls.
Its worthwhile considering project management as the 'how' story that sits alongside the 'what' story. Its development can reside within the team not cast down from on high. The interesting accompanying element for this is the conversation that clarifies a framework of requirements then feeds back the implications to stakeholders - in a broad sense upfront - that onboards team and non team participants. Requirements are another flashpoint for reactions based on micromanaged extremes.
This reads like you summarized my past year - I've been on this exact journey 😀.
And while it's definitely not easy all the time nor an overnight change, once you see it working & taking up steam it feels SO good and rewarding.
I'd maybe go so far as to say it's one of the rare cases where setting this as a goal will trigger / require almost exclusively positive changes. Culturally, it's an approach that forces you to empower & provide context instead of command & control / waterfall.
Every. Single. One, rings true.
I agree with the assessment that tickets and user stories are often abused. They are used as handoffs and to avoid building shared understanding among PMs, designers, developers and other members. In this sense, I think that a team where PMs don't have to write user stories as much as other "typical" teams is a positive sign at first.
But "placeholders for conversations" can also imply that we only need conversations and not stories. Sometimes details are lost and things are not acted upon, even if we talked about and agreed together.
I think the better way to think about user stories are like pictures. When you look at a picture, you recall the details that are not in that picture, but the picture serves a purpose. Sometimes you forget what's there if you never look at the pictures.
So details that we agree upon, acceptance criteria and shared understanding should be captured, preferably in the form of user stories. I think the collective efforts of building shared understanding naturally result in user stories, and so in a sense, "PM's don't need to write user stories" is still true. They don't "need" to write user stories, user stories naturally arise!
When you build something reasonably complex, having your shared understanding captured in ways that we can point at and discuss is pretty useful.
"A user story is supposed to be a placeholder for a conversation."-100%! The entire team, or all that are needed to deliver the story should have a hand in contributing to what goes on the ticket. I think there is still value to writing them. It gives the team a model of level of understanding, but if the team is not having those conversations, that is worrisome.
For years Ive been interpreting the Waterfall v's agile conversation and thinking the driving end point was elimination pert and gant charts (these being seen as the equivalent of waterfall - and a despised practice in the dark arts).
From within the post (worthwhile) the idea of story can include scenario planning and testing via intelligent use of classic project management tools. The strategic development of alternate story plots that are reconfigured to identify and navigate critical elements ahead of just doing it. This is not line by line prescription, that I could see a bureaucrat bent on micromanagement reveling in, the actual Waterfall diagnosis that causes screams and howls.
Its worthwhile considering project management as the 'how' story that sits alongside the 'what' story. Its development can reside within the team not cast down from on high. The interesting accompanying element for this is the conversation that clarifies a framework of requirements then feeds back the implications to stakeholders - in a broad sense upfront - that onboards team and non team participants. Requirements are another flashpoint for reactions based on micromanaged extremes.
This reads like you summarized my past year - I've been on this exact journey 😀.
And while it's definitely not easy all the time nor an overnight change, once you see it working & taking up steam it feels SO good and rewarding.
I'd maybe go so far as to say it's one of the rare cases where setting this as a goal will trigger / require almost exclusively positive changes. Culturally, it's an approach that forces you to empower & provide context instead of command & control / waterfall.
Great to see this getting more attention :)
This finally puts an explanation on what I've felt for a long time