Can you have an episode that describes how to organize the product backlog items such as Epic, Features, Stories? Thanks in advance.
@shawnhughlett16112 жыл бұрын
That's a good one!!
@veccher3 жыл бұрын
Talking about storys, we used the format "as i want to achieve ", at first, i personally loved the approach since it forced us to think about who will benefit from the feature, and what goal we want to achieve, and not only the feature. The user/persona is usefull to see who may be invited to the review, the goal is usefull to understand why we're doing this and what we really need to achieve, but most of the time, we needed to talk about the feature, and having this format was actually confusing, the three informations were in the title, but it made it harder to us to easily look at the PBI and understand what it's about, too much information on the title, led us to spend to much time to look for the PBIs we wanted, so now we started putting the impacted stakeholders/personas in a specific field inside the PBI, the goal is described usually in the feature/epic (azure hierarchy) level, and our base levels PBI's titles are just a simple description of the desired functionality. There's a bonus, letting the stakeholder inside a dedicated field make it easier to us to generate statistics about who is more impacted by our releases.
@MarkBurville3 жыл бұрын
That sounds great Vinicius 👍 if it works good for you, then don't change. I also love the "As a ....". Scrum however, isn't as prescriptive as before, 2020 Scrum Guide, this does not mean you must change what works for your team. Nevertheless, what works for one team will not necessarily work for another team, each team should empirically learn to be effective, in their way.
@clange10593 жыл бұрын
I like to see user stories start with a verb because it's activity the team will be doing. I also like for the story to identify the value/benefit the user will receive. There is some contention on whether or not a team member can be a persona. If the user story is work the team must do to eliminate tech debt or to enable further work, it makes sense to I me that the user is team member. What does the community think of that approach?
@rajkumarmfsr3 жыл бұрын
Thanks Todd and Ryan. Awesome content.
@mohammadesmaeilpedaran70343 жыл бұрын
Thanks for your perfect podcast, I think it's time for having another Fixing your Kanban podcast
@agileforhumans In your experience what are you expectation for a scrum master 30, 60, 90 days of joining a new team?
@paulcasanova48363 жыл бұрын
That's a great question Frank - I'm keen to hear Ryan & Todd's thoughts 👍 As a contractor I'd love to become a helpful as possible, as quickly as possible in each Scrum Master role. I usually just take a Scrum approach to it (probe/sense/respond/adjust etc), but if there are other suggestions that would be great 👍
@FalhenStudios3 жыл бұрын
Hello, I just joined my new team recently also. My suggestion for 1st 30days would be more of observations, shadow your onboarding buddy if you have one and ask questions (One on One) not with the Team though, meet with people (QA,Devs, PMs et al) understanding the organization culture, understanding the products they are working on, observing interrelationships between multiple teams to get the feel of dependencies. In 60days, you should be starting to kickstart your team/sprint 0. and getting to know your team. Will update when I clock my 90days to share my experience again. Nice to meet you and this a great channel to learn a lot to help you on the journey
@ryanceasarborromeo19893 жыл бұрын
In the real world, SM is the one getting sandwich. Hahaha. Especially if the PO thinks the SM is his or her secretary.
@vikassalunkhe3125 Жыл бұрын
Few teams expect SM creates US/Tasks for them and update each comment on it in Jira.
@opmdevil2 жыл бұрын
As a product owner I want that the team will write user stories so that I can prioritize the backlog with all relevant information at any given time.
@mac1414 Жыл бұрын
Ah brilliant. Sounds like PO is literally redundant or useless. Since everyone else does 99% of the work why bother with POs if all they do is sort backlog by priority? Devs can easily prioritise backlog just in a single grooming session a week, and Lead Engineers / Team Leads typically are also present when talking to business. Sounds like we went extreme from PMs doing way too much to POs doing nothing at all.
@kensaiyeahyeah1233 жыл бұрын
What are you drinking Todd? Scrum juice? 😀
@AgileforHumans3 жыл бұрын
Just water. I drink Scrum juice during Craft Brewed Agile 😂😂😂
@69sachu3 жыл бұрын
If not user story, then what are the other ways in which Product Backlog Item can be captured?
@AgileforHumans Жыл бұрын
Job stories or hypothesis driven development are two alternatives I've used before. - Todd
@brunolopesmello19869 ай бұрын
Business Stories, Kaizen Stories, Enabling stories, Technical Stories, you can create different structures that considers specific criteria's that are valuable for the outcome expected of the work. If there is no direct impact on the user, there is less or no value to write it from the user's perspective.
@dragonlordship Жыл бұрын
Please explain that why it is called stories ? Not work items or artifacts!!!
@AgileforHumans Жыл бұрын
In Scrum it is called a Product Backlog Item (PBI)