Mine, too. I have many great memories of reading to my daughters before their bedtime.

😀Thanks!

Thanks, Mad Dog!

Sorry, I don't know as I don't use either.

Definition of Done is for all stories. Acceptance Criteria are for specific stories that need to be met in addition to the Definition of Done.

Every career move is different for each person. The simplest way is to get a job as a Product Owner. Apply for PO jobs and try to get hired as one. However that's not always possible and, in general, experience is favored when changing careers. Now that you're certified and understand the role of a Product Owner; try to gain experience in that PO role wherever you can. If you're able to take on some of the responsibilities of a PO at your current company then do so. If that's not possible you might want to consider donating your time and skills to a local organization that you align with. Oftentimes local non-profits will be very happy to give you the necessary job experience if you offer to volunteer with them. Don't replace your job with volunteer work, but in your free time, volunteer as a PO with that organization to gain some experience.

@@MountainGoatSoftware Fantastic advice, Mike. Appreciate that. I've been applying, but the volunteering work is a good steer. Many thanks!

A team has authority to change its own sprint backlog. Team members should consider running things by their product owner. But I wouldn't want to spend an hour tracking my PO down and then 30 minutes seeking permission for the 2 hour thing I want to work on. Team members should use their judgment.

If they don't have the authority to make the decision, they should ask the person who either has the authority or who can give it to them.

There are often ways to write a sentence that includes two goals. But that's just playing games. Write a goal that includes two goals if needed. I think the point should be to have the discipline to try to focus on one thing.

Thank you.

Thanks.

Thank you.

A dependency does not increase the effort to do the work so it wouldn't impact the estimate. It should, however, be something a team accounts for when _planning_ which should be a different activity from estimating. Typically, a team would plan to get the work from another team in advance of their own work. I will sometimes add a "nag task" to a sprint backlog in those cases--e.g., "Nag other team to give us xyz by Monday."

I'm planning a new video on that. It will probably be a few months out, though.

Because the terms agile and scrum will become so common that people will assume that when you say that you're on a development team you're on an agile team

Yes breaking down work into pieces that you can complete and get feedback on is important. But creating a feature team doesn't mean that we reduce the number of people on the team. A feature team should have everyone necessary to deliver the feature. So in the sticky note example instead of having 2 separate teams (frontend and backend) we would have one team that has both frontend devs and backend devs working together to deliver the feature. To your point about incremental work. If you had those 2 component teams, you could probably create 2 feature teams form them, each of which would be able to deliver entire features instead of half a feature per team. Just in that release cycle alone you'd double the amount of feedback from stakeholders (the more you complete and show to stakeholders the more they can actually provide feedback on).

Thank you!

Those are great things to do, but you can create all the prototypes you want and there will still be things no one has thought of.

​@@MountainGoatSoftware Absolutely but it also depends on whether the product is new or if we are adding new features to an existing product

I answer all of those questions here: www.mountaingoatsoftware.com/blog/what-are-story-points

Thanks, Pedram.

I wouldn't suggest tracking individual productivity. I just don't see much of a benefit in that. I do, however, see benefit in empowering a team enough to self-organize and decide how much they will be able to reliably get done. Then use those estimates as data for future estimates farther out than a sprint or two.

@@MountainGoatSoftware Is there a way to measure self organising ability ?

@@rajeswarikv9396 No.

@@MountainGoatSoftware What if a team does not have a sprint goal in one or two sprints? Like there are many defects,technical debts and each one picked each item and no common sprint goal? Still do they need to colloborate even for defect fixes and debts fixing?Is it still a shared effort? And wat to show in sprint review in this case?Kindly clarify

@@rajeswarikv9396 I have a set of videos about sprint goals, please start with this kzbin.info/www/bejne/emnSiKh4eNpnrZI

Yes, I have a video on it here: kzbin.info/www/bejne/aoS5qIF8aNaokNE

Glad you like it!

Agreed. All this should be discussed in sprint planning.

You're welcome! Glad you like it!

I wouldn't necessarily re-estimate the story during the sprint. You're going to discover new things as you work. If this is the first time that this happened; finish the story as normal. You'll probably have to push some other stories to the next sprint and your velocity will be lower than normal. Don't worry. Take some time during your retrospective to talk about the story. "Why didn't we realize that the story was this big?" "Did we learn something during this sprint that made the story bigger than we originally thought?" "Did we just miss the mark on this one?" "What can we learn from this so we don't repeat on future stories?" Understand why it grew to be so big and figure out what steps you all can take to help mitigate that in the future. If this is a reoccurring issue, have your team leave room in the sprint for this. Bring in fewer stories and create a buffer for when this happens. We don't want to spend a lot of time figuring out every little task that is associated with each story. It just wastes a lot of time. Our goal is to know enough to get started, then start. We'll learn more as we work and get more done.

Thanks Mike ​@@MountainGoatSoftware Velocity can't be guaranteed to increase.. Most of the times,planned velocity will not be met and will spillover.. Management expects that velocity needs to be increased as the team matures.How to convince and make them to understand

I address that it one of my courses. I'll see if I can make a video on it for here.

@@MountainGoatSoftware ok please.. Thank you

You're welcome!

Those got added somehow when a translation was done.

I'll add "a day in the life of a manager" to my backlog for a video. In the meantime though, we made a podcast episode about The Role of an Agile Leader: www.mountaingoatsoftware.com/agile/podcast/70-the-role-of-a-leader-in-agile-with-mike-cohn

I wrote an article a while back showcasing what managers role is on self-organizing teams: www.mountaingoatsoftware.com/blog/the-role-of-leaders-on-a-self-organizing-team I'll be sure to make more videos clarifying what managers do.

Thanks, Dave--and that is excellent advice. We all need to remember to ask for help when overwhelmed.

Excellent, Brian. Thanks for sharing.

You're welcome!

If you're just getting started in Agile or Scrum we have a lot of resources on our website here: www.mountaingoatsoftware.com/agile/new-to-agile-or-scrum

I don't fully understand what you're asking clarification on so I'll share the differences between capacity-driven planning and velocity-driven planning. Capacity-driven planning is where the team takes a backlog item, quickly estimate the tasks, and decide if they can bring it into the sprint. If they decide that they can bring it in, they repeat that process until they feel like the sprint is full. If they decide that they can't bring it in, they might look ahead an item or two to see if one of those are small enough to bring in, but ultimately the sprint is full and no more work will be brought in. After the team decides that the sprint is full, the Scrum Master will add up all of the points associated with the estimated work and compare that with the team's velocity as a sanity check. Velocity-driven planning only takes into account the team's velocity. Some teams only take their most recent velocity while others will take their average velocity. The team will look at the backlog, take an item off of the top, add the points of that item to a running total, bring it into the sprint, and rinse and repeat until the running total for the sprint is the same (or close to the same) as their velocity. In it's most basic sense velocity planning is done. But it's helpful for teams to break down each item into a list of tasks, then quickly estimate how long each task will take and compare that to the total number of hours that are available in the sprint as a sanity check that the right amount of work was brought in. For short term planning I much prefer capacity planning but for long term velocity planning works well. Here's an article i wrote sharing why: www.mountaingoatsoftware.com/blog/why-i-prefer-capacity-driven-sprint-planning

​@@MountainGoatSoftware1.In capacity based planning the estimation is based on hours..2.Where did the story points come from and why are we comparing points and hours during sanity check?3.Is there a relationship between story'points and hours?I am sorry this sanity check is not clear

Ultimately we are limited by time. No matter how much money, energy, or effort I invest in a project, there are 24 hours in a day. There are multiple studies that have shown that we are really working about 3-6 hours each day. The sanity checks are there to verify that the team hasn't brought in more work than the 3-6 hours that they have each day to actually complete. There is no correlation between story points and hours. If my team brought in 20 points and during our sanity check they quickly estimated that it would take about 80 hours to complete then we've brought in too much and we should cut some stories. If your team brought in 60 points and said that it would take about 40 hours to complete, you're good to go. It's simply a quick validation that we aren't bringing in more work than we have time to do. There is no comparison between points and hours in our quick sanity check. In capacity planning the team collectively decides how many hours they have available this sprint and determines what stories they can complete with that set hour limit. If a team says that they have 40 hours available this sprint, has a velocity of 20 points, and they bring in 60 points of work in. We need to have a discussion about the work that they think they can do in 40 hours. This sanity check is there to validate that we aren't overestimating how much we can get done in the time that we have. In this example it could be that the team normally only has 10 hours of availability so this sprint they can get significantly more done as they have more time

@@MountainGoatSoftware ok Thank you.Instead , we can calculate available productive hours of the team for a sprint (capacity) and compare with estimated hours for the tasks and see if we are planning enough within the capacity limit (to see over or under estimations)..That's how we do .

@@rajeswarikv9396 Yes.

Yes, split it by acceptance criteria if you cannot finish. Add a backlog item that describes the remaining acceptance criteria.

@@MountainGoatSoftware In that case can we take this in sprint review with stakeholders on the splitted and completed story

@@rajeswarikv9396 Yes, you do still want to be a little careful of a team splitting something "too late" in the sprint (like the last day!) just so they can get credit. Normally when a team does that they take more credit than they've really finished in the subset that's done. That feels good because velocity is higher. But if we use that artificially high velocity to make predictions about future deliveries, it won't feel so good when they end up being late or under-delivering because of it.

I'm talking here about stories that are further out than the current iteration. If you're bringing a story into a sprint, you should try to split it small enough to be done within that sprint. Sometimes that's not possible, but it almost always is.

That's a very challenging situation to be in. You might be able to shift your team's view on the Sprint Review by highlighting specific instances where stakeholder feedback led to important pivots or improvements in other projects. Carrying over work each and every sprint could stem from a lot of different things. Underestimating tasks, not fully understanding stakeholder needs, or just constantly overcommitting. It sounds like you've had conversations with your team encouraging them that they need to slow down a bit in order to ultimately speed up later on. It might be helpful to step in during Sprint Planning and encourage the team to commit to a very low number of stories. If they normally bring in 50 points worth of work, only bring in 25 points one sprint. If there's still carry-over drop that down to 10 points. The goal is to finish what we commit to so that we can build predictability and trust with our stakeholders.

@@MountainGoatSoftware thank you so much for your response. I had a look at a few more of your videos and managed to sell the team on committing to significantly less during our sprint planning today. Let's see how it goes 😁

@@hellglazer Great news. It's really good to break the habit of constant overcommitting. Please come back at the end of the sprint and let us all know how it went. Good luck and thanks!

@@MountainGoatSoftware well we eventually managed to deliver what was committed to😁 now we're needing to think about pulling extra work. But not quite yet. I want to make sure we're not purposely under committing now 🤣

@@hellglazer That's great. Thanks for coming back to let me know.

Thanks, Geena. It was fun to make.

Thank you very much.

Thanks. I appreciate it.

You're welcome. Thanks for watching.

Thanks. Yes, it's frustrating when a PO goes directly to a specific deliver to slip something into the sprint.

I'm okay with some overlap but it shouldn't be so much so that we stand in our own way. If a stakeholder wants to be on the team level they can come to the daily scrum...but they shouldn't disrupt the team in it.

Thank you!

Thank you.