YDS: Who Writes User Stories on a Scrum Team?
Вставка
- Опубліковано 1 жов 2024
- Who writes the user stories on a Scrum Team? Let's explore the options this situation presents. All of this and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley.
What do you think? Let us know in the comments!
Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems -
amzn.to/3fMpH5a
Join Ryan and Todd in a Professional Scrum Master course:
www.scrum.org/...
And make sure you subscribe to the channel!
DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week!
FTC DISCLAIMER: This video is not sponsored by anyone.
Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems.
#scrum #agile #scrummaster
Can you have an episode that describes how to organize the product backlog items such as Epic, Features, Stories? Thanks in advance.
That's a good one!!
In the real world, SM is the one getting sandwich. Hahaha. Especially if the PO thinks the SM is his or her secretary.
@agileforhumans In your experience what are you expectation for a scrum master 30, 60, 90 days of joining a new team?
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 👍
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
What are you drinking Todd? Scrum juice? 😀
Just water. I drink Scrum juice during Craft Brewed Agile 😂😂😂
Thanks for your perfect podcast, I think it's time for having another Fixing your Kanban podcast
Excellent question, perfect 20/20 response. Friyay RR TM.
Thanks Todd and Ryan. Awesome content.
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.
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.
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?
Few teams expect SM creates US/Tasks for them and update each comment on it in Jira.
Please explain that why it is called stories ? Not work items or artifacts!!!
In Scrum it is called a Product Backlog Item (PBI)
Thank you guys
If not user story, then what are the other ways in which Product Backlog Item can be captured?
Job stories or hypothesis driven development are two alternatives I've used before. - Todd
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.
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.
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.