Have you seen this issue with your teams? Do you see vague & misunderstood (and potentially large) but novel & innovative pieces of work being pushed down the priority list? How do you fight this problem? I'd love to know your thoughts, let me know in the comment section below 👇
@scoogsy
Жыл бұрын
We define business value before we set acceptance criteria in our backlog. That means that we start by grooming, our backlog in terms of priority around perceived value. After that we look at the highest value items, first in the backlog and start refining them, which includes the process of acceptance criteria.
@TheAgileBroadcast
Жыл бұрын
And that's the way to do it... But the point here is that: what happens when refinement doesn't work well because there are e.g. too many unknowns, uncertainty, etc. It's a pattern I've seen that the Devs push back on those because "they are not ready". By pushing back, things are postponed, which means they are effectively deprioritised... And that's no good if the ticket item is high value
@scoogsy
Жыл бұрын
@@TheAgileBroadcast nice. I wonder if at that point it’s about rescoping the outcome of the backlog item, or perhaps creating a linked item if you get in that situation which is a POC or discovery task, which feeds back into the real deliverable?
@TheAgileBroadcast
Жыл бұрын
Bingo! 🙂 That is exactly what I often encourage teams to do as a practice to deal with that problem. The bigger (somewhat philosophical) point here is that, by doing this, teams can move into owning the problem space and behaving more like a true product team, compared to being a feature factory team. So a great tool to have from a coaching perspective
@scoogsy
Жыл бұрын
@@TheAgileBroadcast yep that makes so much sense. Thanks for the insights!
11 ай бұрын
Hi David - thanks a lot! My question is somehow directly related to the video. I'm wondering how detailed the acceptance criteria should be. What level of description should Product Owners include? For instance, should they avoid mentioning basic or obvious steps (such as stating, "Here's the button, when the customer clicks it, it redirects to...") and instead focus on writing from the user's perspective?
@TheAgileBroadcast
11 ай бұрын
Hey Deniz... Best if they are written from the user's perspective, though it can be quite difficult sometimes. One trick to keep in mind... when a story is deemed too big (to fit into a sprint for instance), you can split the story by acceptance criteria, so that each criteria becomes its own story. One more thing... it doesn't have to be the PO doing this alone. It should be a team activity!
@Tony-dp1rl
Жыл бұрын
Are the scenarios you are talking about here those items that lead to "Spike" Stories, or something else? i.e. that is how we handle those big not-yet-defined stories.
@TheAgileBroadcast
Жыл бұрын
Spikes, yes. It's one way to time-box some investigation/de-risking activities. It's easy to abuse it though and fall into the "we need to know/understand everything before we can start". These are great for when the uncertainty is technical. But when the uncertainty is around the requirement itself, i.e. is this even the right thing to build? Further slicing of the story would be better IMO and then you can build the "MVP" for that feature to learn and adapt.
@rrkarthikeyan3697
Жыл бұрын
Should the developers develop only what is mentioned in acceptance criteria??
@TheAgileBroadcast
Жыл бұрын
Hey, thanks for the question. Could you elaborate? What exactly is the issue you're facing? If developers put more effort in by adding more features that are not needed, what's the point of that? But it can also be the case that, while developing, you discover that the original acceptance criteria were not enough to be satisfactory... In that, well, just update them!! That's the whole point of working agile.
@professionellatv_
3 жыл бұрын
This was great, I’m working on a request process for our stakeholders and want to make sure we don’t fall into this problem. Especially as you said stakeholders need to see “it” in order to say what they like/want.
@TheAgileBroadcast
3 жыл бұрын
Glad you liked it! It's indeed very easy to fall into this trap of doing what is known first and thus always postponing to later what is unknown/vague.
@dasraja4479
3 жыл бұрын
Teams adopt this defensive mechanism to protect themselves from management’s obsession in measuring committed vs actual delivered. When things are vague (even though valueable) teams are not motivated to explore the opportunities behind them. They are just trying to protect themselves from middle management.
@TheAgileBroadcast
3 жыл бұрын
Well said 👍
@mikechavannes5357
4 жыл бұрын
You bring up some very good points that I think will be a very important deviation from the norm for a very large project for which I'm currently a scrum master. I'd like to hear more of your thoughts on this. What I typically do is try to break the larger, less defined projects or user stories into smaller sub-stories where the deliverable may not be a finished product, but more of a more fully developed concept that can be built upon.
@TheAgileBroadcast
4 жыл бұрын
Hi Mike, Glad to hear this might be useful to you. Breaking large items of work into smaller ones is, of course, a good thing to do... the problem is that you cannot do that for all items up front (well you could, but then you're back to a "big up front design"), so you have choose between the ones you define now, and the ones you leave vague (to be defined later)... it's a balancing act between the risk of defining too much too early and defining too little too late... For me, the important thing is to prioritise the work so that you 1) deliver value by building what is known/understood and 2) de-risk the unknowns (by doing spikes, building MVPs, prototyping, etc.)... and we have to do 1) and 2) at the same time... that's the challenge: doing delivery and discovery at the same time. Does this help at all?
@professionellatv_
3 жыл бұрын
@@TheAgileBroadcast what fascinates me is having to do all this while also deploying . How do you target a number of story points for discovery, delivery and deployment? Especially as the team gets to know one another better and may want to challenge themselves to take on more story points.
@TheAgileBroadcast
3 жыл бұрын
Great question! In my experience there will be sprints with lots of delivery and little discovery, while other sprints might be full of discovery and have little delivery... And because discovery cannot be measured in story points, you might end up looking "bad" because only a few story points have been delivered... The temptation is to then have 2 separate teams: a delivery team and a discovery team but that's a bad idea in my opinion. The "us and them" separation between the people who decides what to build and the people who build creates unnecessary barriers/handovers and slows down the feedback cycle. With a single team doing both, you have to accept the ebb & flow of delivery that ensues. And the leadership has to then see that learning and discovery is a good thing and not beat people up when delivery has slowed down because of it. Makes sense?
11 ай бұрын
@@TheAgileBroadcast Thanks David! Question: How can we ensure that we allocate enough time for discovery as a team? Product Owners and Scrum Masters might also face pressure from a line manager who pushes for rapid deployment. In such cases, the team might end up with shorter sprints because management is eager to go live as soon as possible. How should we handle this situation?
@fredrikvestin752
3 жыл бұрын
I don't see the conflict. If you have a PBI that is unclear, but high prio, then discuss what is the first/minimum thing you could try to learn more and start with that. For that piece of work you might be able to define some acceptance criterias.
@TheAgileBroadcast
3 жыл бұрын
Hi Fredrik, what you describe is the right thing to be doing: You don't push back on that vague but high prio piece of work, you actually tackle it head on. Unfortunately I see so many teams not doing that at all and pushing back on the work because "it's not ready" and using the lack of fully formed acceptance criteria as the excuse for pushing back.
@raykaelin
Жыл бұрын
Sorry dude but your English articulation is hard to follow, confusing, and a bit muddled. Try to FULLY pronounce your words and I believe it will be easier to listen to what's being said, or not.
@TheAgileBroadcast
Жыл бұрын
WTF. What a rude and condescending comment. Go and rethink FULLY how you deliver feedback and I believe it will be easier for others to acknowledge what you say, or not.
Пікірлер: 25