Product Backlog + FREE Cheat Sheet
Вставка
- Опубліковано 5 бер 2019
- We're looking at Scrum in detail. Today it's the turn of the PRODUCT BACKLOG.
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmentthatpays.com/w...
= = = = = = = = = = = =
Grab your FREE Scrum Cheat Sheet: www.developmentthatpays.com/c...
-------------------
134. Product Backlog + FREE Cheat Sheet
#ProductBacklog #AgileScrum #DevelopmentThatPays
The Product Backlog is an ordered list of everything that is known to be needed in the product. That’s how the Scrum Guide describes it…. And the Scrum Guide goes on to dedicate a fair few column inches to it. The Product Backlog is one of the three Scrum Artefacts - along with the Sprint Backlog and the increment. The Product Backlog sits here - outside of the Sprint “process”... but a key input to it. Without the Product Backlog, there’d be nothing to talk about in Sprint Planning… and nothing to put in to the Sprint Backlog. If I zoom out further to the overall agile flow We see than the Product Backlog is the “vessel” the collection point for feedback received from the the customer - as well as from Stakeholders and from the Development Team. Worth mentioning here that … just as this flow is not unique to Scrum… the Product Backlog is not a “construct” that’s unique to Scrum - it forms part of every Agile Framework I’m aware of. We have a well-defined way of getting items out of the Product Backlog - that the (ritual - the event) of Sprint Planning. Getting things into the Product Backlog is less well-defined But at least it does have an owner - the Product Owner. We talk much more about the Product Owner in another episode, but when it comes to the relationship between Product Owner and Product backlog…. The Scrum guide could hardly be more clear: The Product Owner is the sole person responsible for managing the Product Backlog.
• Product Backlog + FREE... - Навчання та стиль
Here we go again with another bite-sized piece of Scrum. Hope you like the animations 🏄♀️
I really appreciate your videos. You have been a huge help to me. Thank you for putting the time in to do these.
Thank you. Always great to hear that the videos are useful. 👍
Love it Gary. Thanks
Nice explanation of the backlog related processes, Thank You! My personal practice is to refine only those stories that are about to be considered for inclusion into the sprint. Except that I am not the PO, I am the BA, and if the PO requests to work on backlog items that are at the bottom of the pile, I help as much as I can. In the end it is the PO responsibility to set direction and decide what is going to be next.
Pablo - Sounds like a pragmatic (and non-wasteful) practice to me.
Very Well Done .. the graphics were perfect... I fully agree w your idea - serves v. well for perfectionists.. Many thanks !!
*@Development That Pays* at 2:07 you say "Getting items into the product backlog is a little less defined".
I'd love it if you made a video on the process of "Ideas" turning into "Backlog items". I've been using the GTD method for this but I'm curious to hear your thoughts
I agree with you , items at below can be ignored in product backlog , until there are moved up in the ladder to Target for refinement.
👍
I love this video. Do more please
More on the way!
One more excellent video. Great job Gary.
One question: Can an item be removed from the product backlog in order to keep a max size in the list?
That is an awesome question.
If the product backlog has max size... and it's at its max size (it's full)... and a new item arrives... what do we do? I guess we have to decide whether it's more important than the least important item currently in the product backlog. And to do THAT, we need the entire backlog to to be fully refined at all times. See where I'm going with this?
Hi.. I always had this question.. How do you create a product backlog for a new product development that plans to release an MVP, where we have certain list of features to be delivered as a part of MVP?
Nice explanation... I have one query... Would really appreciate if you ans
How can we check the health of pdt backlog?
Do we have any metrics in place to identify pdt backlog health?
Thanks
It's nice explanation
Thank you!
We have a tendency to estimate all items in the backlog. I'd prefer we did not (i.e Lean) and thus lean towards Kanban and/or SAFe. Thanks for these great video and learning opportunities.
I feel for you! 😱
Regarding the idea of accepting all into the product backlog, but only refine some of them, it does sound good in theory.
Taking the other side as a mental exercise, I might refine more of the lower echelons if
- the Product Owner (and assisting team) is not very experienced with refining, and could use some more practice
- the users are not very responsive or descriptive when it comes to what they want, and they need a little programming - if you want something, be prepared to get lots of questions about it
- hidden dependencies might get flushed out, and suddenly a bottom tier PBI has to take the elevator up in a hurry so another item can be delivered of greater value
Refining the top items is what I do too. No point wasting time for all the items, if their time comes, they will get their turn.
My problem is with long-term, large tickets that may be down the list somewhere, waiting to be refined, while during the refinement process itself, it might turn out they actually have much greater priority or complexity than initially assumed.
Your thoughts?
Some people advised: before putting it into z ProdBklg just ask 3 questions (categories)= is it CRIT for customer value; or is it IMP; or Not-IMP = later on you may add z details & estimates; or even reshuffle it into another category
I would say by the very nature of refining and constantly manageing the product backlog, its natural due to time constraints and the importance of the items in the top of the list that people naturally ignore the items at the bottom. But people don't what to just purge what was captured due to the good intent of eventually getting those items implemented, because they might not bring as much value but provide good polish to the product when enough of them have been implemented. Due to this I think those items at the bottom end up there naturally and I wouldn't say that is a bad thing.
To me its a potential polish that one day can be added as value to the product, once all of the higher priority items at the top of the list finally get finished and things start to slow down. A lot of the times, it is just to hard to refine EVERYTHING due to the time needed to invest in doing this. Especially when those items at the bottom of the list are not on peoples minds at the current time due to the "importance/value" of the items at the top of the list.
I say ignore them and there potential can definitly shine one day. And if not and they get deleted, thats ok too!!
Agreed!
I’ve been battling with the ‘refine all’ vs ‘groom as you go’ and still haven’t found a solution. I work for an agency (smaller, one-off projects commonly) and my PO always wants estimates on when we will complete the project. Unless we story point a refined backlog, the dev team can’t story point everything accurately. There are just too many unknowns.
So depending on the size of the project, I aim to refine as much as I can before we kick off. I feel like this isn’t always the best approach, but for short term projects, I guess it isn’t too much wasted effort if things/priorities change. I can see this being very different if we were enhancing an existing, long term product though.
Does anyone have a good approach for the agency world? How do you apease your PO/stakeholders lust for deadline dates?
Did you found an answer after 1 year?
What exactly the difference between User Story and Story Points in Iteration Plan of gile Methodology.
7:47 agree in principle. However, if you have the product owner as a couple, they'd be able to refine more. The thing is there should be a query to sort by business value, architectural value, INVEST criteria and understanding as a whole. Sometimes we do get information overload, but you can't use that as an excuse to ignore the bottom ones. If it went to the backlog, it was important to someone at some point.
The product owner is responsible for contacting the originator to see if it was addressed.
A future state of my organization (we haven't organically got to that point yet) is to treat the product backlog with a Kanban methodology with columns like Backlog -> Criteria'd (i.e. INVEST flags have been set, values and risks noted and Story Pointed) -> Refined (at this point INVEST flags are all set to true or additional stories are created referencing this one and this ) -> Active (it is actively developed) -> Resolved (its in a integration environment) -> Closed (It's in production)
The last 3 is already in place, its just the first few are just lumped as "New"
Great stuff. My "top middle bottom" (of the product backlog) is a (very) lightweight version of what kanban (as you described it) does more rigourously.
@@Developmentthatpays maybe update it so it is referenced that way BUT don't call it Scrum, since any deviation is not Scrum anymore.
Where did I deviate?
@@Developmentthatpays It's been a week since I posted that but if I recall its because you were doing a light-weight version of kanban.
following him Master, every last video
Excellent! Thanks for watching.
Good video Gary. My curious thoughts to ask from the video is if the backlog deemed divided into top part is valuable, middle part is “to be refined later”, suitable I guess from short-term to mid-term priorities then bottom is controversially ignored. Let’s say for a fictional example HR department has files of resumes adopting scrum as in a folder online somewhere as their backlog a big one. The current ones reviewed can be deemed suitable to pass onto management as their sprint as their next interview stage, returning back to the backlog I wonder what remains in the backlog as ignored section...those resumes missing out opportunities/possibly creating ethical concerns for various reasons. Would the product owner know those items left behind could impact their legal if ignored or it is fair if documentation is reflected a decision made?
Could it be that that's a process where an agile approach is not appropriate?
so it’s the role job to know the difference and their decisions regarding what’s in the backlog...makes sense.
Another approach would be to have some kind of trigger - based on dates - to have backlog items "wave their hands" when reaching a deadline.
agree with you, why wasting time, those may not see the light even and chances are there for owner to removed them from the PBacklog
👍
Agree
👍
We tend to estimate everything and use a User story map as the product backlog
Very interested in Story Mapping at the moment. I get that you would want to estimate everything in your story map; but is everything in your story map?
@@Developmentthatpays not everything... But yes everything, I'm working in an agency environment so everything the customer thinks they need up front goes on the map and gets estimated so we know roughly what range of effort might be required. Really enjoying the story mapping works great for customers and the dev team.
Curious to know how you first started with Story Mapping?
@@Developmentthatpays have only just started with Agile (Scrum) and through lots of research (watch UA-cam videos) I stumbled across it and it felt like a really nice visual way for us to communicate with our external customers. It really helps paint the picture with them as to the size of the project and it helps the customer to see what really is of value.
why do the items make it onto the product backlog if they will not move up the list to eventually get built?
Simply because priorities change. What was required (say) last year might not be required today.
If it can be ignored, it's nothing but noise. But you mention a caveat that if the low items manage to make it to the mid range, then it's no longer ignored. Grooming is painful because of this. We tend to ignore the non "squeaky wheel." We do this at the cost of customer satisfaction. Everything on the backlog made it there for a reason. Ignore that at your own peril.
Maybe ignore was too strong a word.
Here's a question for you: Let's say we refine everything in the backlog. Including the item in position 302. Six months later, "302" finds its way to the top. QUESTION: can we send in straight for development?
I agree, I think we should groom it. Which means it was groomed twice. So the first was a waste of time/effort. See what I'm getting at?
@@DevelopmentthatpaysA lot has changed since we place this item at 302. Obviously, because now it's jumped the shark.
Is this guy Mr Bean? But thank you for the video
I'll take that as a compliment. Rowan Atkinson and I grew up within a few miles of each other. 👍
@@Developmentthatpays Yes it is ... You really look like him and He is one of my favorite actores... And u are an amazing tutor ... THANKS