Video

Thanks. And I'll look forward to seeing you in a CSM class.

Given that managers aren’t involved in estimating or using story points, I have no idea why they’d make them feel important.

Uhh, no. We've actually know for nearly 120 years that time is not a constant. And I'm not sure why a manager (or "manager") would want to play jokes on an employee. Story points are useful in discussions between two team members who produce at different rates. A junior programmer may say something will take a week whereas a senior may say a day. If they argue in days, they will never come to agreement. Those two, who produce at different rates, can agree, however, that the thing will take half as long as some other thing.

I don't think that's always the best course of action. Your subject matter expert (SME) might take on too much work, it opens the door to your SME to being a potential blocker for others, and what happens when your SME get sick? Or goes on vacation? Does all work just stop until they're back?

In a story map, multiple cases are visualized by placing stories across the grid to show the sequence in which they'll happen and down the grid to show alternatives. If there are multiple ways to achieve the same goal, those alternatives would be stacked vertically. The backbone isn't necessarily treated as an epic. The backbone represents the new or improved functionality users need and can be thought of as the topmost narrative in the story map. An epic isn't considered completed when the MVP is released. The MVP represents a subset of the functionality that delivers value early, but the epic may still have additional activities that need to be completed in subsequent iterations. So, if the MVP is released but the epic still has activities, it means that the epic is not yet complete. The remaining activities will continue to be worked on in future iterations until the epic is fully realized.

@@b0mazor If it’s just you then stick with days. Story Points are useful when a team needs to agree on an estimate. What a junior and senior dev think of as “one day” will be different. But (generally) the junior and senior can agree, “this will take twice as long as that.” That’s when story points can be useful.

Yes--use short verb phrases like "clean dishes" or "order meal."

@@MountainGoatSoftware , thanks. Not everyone, especially in management, really gets it. I will use your answer as a reference next time I have to persveide them.

You're welcome! I'm glad you find a lot of value from it. Knowing some UX design will certainly help enhance the story mapping process (you'll be able to provide more insight into user interactions and needs), but it isn't a prerequisite. The focus of story mapping is on understanding the sequence of user actions and identifying gaps or missing information, which you can do without having a deep knowledge of the UX design. So I'd caution you about mapping out every object before coming into a Story Mapping session.

I appreciate that. Thanks.

Thanks, Michael. I appreciate it.

Great question. I'd start out with one map but would very willingly create a second if needed. Sometimes the differences can be minor (but important). I'm thinking about the check out process on Amazon for prime vs. non-prime members. If 80% of that is the same I'd stick with one map (for simplicity) and just draw a little symbol on the cards that differ (or use a different color). But if the users are very different (normal user vs sys admin or such) start with separate maps.

@@MountainGoatSoftware that's great! Thanks a lot! I appreciate it

@@ed8574 You're welcome

Thanks for the question and for the answer. Recently I was finding it very difficult to get some expert answer on this specific question. Thank you once again 🙏🏻.

@@ajaygovinds You're welcome.

Thank you.

I think of that as the product owner's responsibility since they'll be the main user of the feedback notes. However, product owners are usually way too busy during the review to also be taking notes. So I coach the Scrum Master or a team member to offer to help out. Almost every team has someone who is super detail-oriented and is quite willing to help out. A lot of times, a tester is the most organized and will do the best job at taking those notes.

@@MountainGoatSoftware Sir, PO acts like a stake holder or the end user in a review and provides feedback along with the stakeholders.Scrum master shall record it and take these as inputs for retrospective.This is what our agile coach guides us, Please correct me if my understanding is correct.

@@rapra4024 In some organizations, the PO is a recipient of the demo given during a sprint review. In others, the PO is a more engaged participant and may give the demo. I'm sure your coach has recommended the right approach for your organization.

Yes, I am absolutely recommending that a team have some sort of idea where they are headed that is further ahead than a week or two. Having no plan further ahead than that is suboptimizing as a team moves from one quick goal to the next. Nothing about knowing where to go says that the plan cannot be altered as more is (inevitably) learned while moving toward the goal. The problem comes from people taking a destination as unchangeable rather than having some larger goal in mind.

I don't recommend having such a complicated hierarchy.

Thanks.

Good analogy! But I don't think many lumberjacks would say that you can have too sharp of a sawblade. I do believe that you can do too much upfront thinking....much like you can over-purchase insurance. Like taking out a $1million policy on a car only worth $1,000, too much upfront thinking is very costly

Thanks, Dave. That's very kind of you to say.

Going back to the old days of development would be tough. Even for those who aren't fans of agile and scrum

Requirement can be a bit ambiguous. In some contexts it can be used to describe detail specifications or a user story that needs to be fulfilled. With Azure DevOps using it as an intermediary level, you might run into some confusion if you have team members who are used to a different definition of the term. As long as you're all on the same page about these definitions and consistently use them accordingly I don't see an issue.

@@MountainGoatSoftware thanks!

Thanks, Helen. I'm not sure I can add much more to what is in the video. I think it is acceptable to forgo a sprint goal when there is no unifying theme or single goal for a team's work. When possible, identify a sprint goal such as, "We will accomplish/achieve/deliver x." If necessary say at most perhaps, "x, y, and z." Each of those could possible cover one or more things (features). I think your mention of devs sticking to their strengths is unrelated to having multiple goals. If not and you have multiple goals because each person wants to work on just one thing and own it, that is a problem I'd suggest addressing.

@@MountainGoatSoftware I absolutely agree - it's a long term goal we're working on moving to a more T-based shaped team. Thanks Mike.

Excellent! It works well and I like your description of keeping goals fresh.

I'm glad it was helpful, Johnny. Everyone wants to make things so complicated.

I've never seen use cases placed on a story map. Use cases tend to be much larger than user stories, and there is already a Use Case Diagram approach for visualizing use cases. If you're using use cases and stories together, you can think of the use cases as an epic (big story). The individual paths through the use case or the steps within can map to stories.

😀Could be and I wondered if that was the case.

Great!

Yes, you can combine the two approaches. For example: _As an Amazon Prime member, _*_when_*_ my subscription is about to renew, I'd like to be notified so I can cancel if it I'd like._

Yeah, it makes a lot more sense to simply combine them. The "job story" loses value by removing the role.

Hi Abhishek, It sure is nice to have options. And I think you've got two good possible directions. I can try to give you a few things to think about to help you make a decision. First, look at the blogs, books, and articles you read over the past year. And the podcasts you listened to. Were they technical about how to do your DevOps work better? Or were they around product management or management in general? That can help you see where you're most passionate. Second, and this may sound silly but write a little "user story" about your life over the next year. Write a paragraph or two, no more. What will you do each day or week? Will you be working longer in one (but enjoying it more)? Will you make more in one and how important is that? Will it lead to opportunities you wouldn't get otherwise? etc. I did this 23 years ago. I had an opportunity to work as a VP at one of the big tech companies, work as CTO to help a startup get funded and go public, or be an independent agile trainer. (I went with the startup, telling them I'd do it for a year. It worked out well.) Writing something like this may help you see wich you have a preference for. Next, here's a blog post I wrote awhile back on assessing if a company is really agile. www.mountaingoatsoftware.com/blog/three-questions-to-determine-if-an-organization-is-agile You can also ask the manager, which product management leaders he follows or respects. That will tell you a lot. (And be a useful tip when you start the job!). Finally, Christina Ambers and Brian Milner have a good podcast episode about assessing a company culture before accepting a job. It's here: www.mountaingoatsoftware.com/agile/podcast/how-to-assess-company-culture-before-accepting-a-job-offer-with-christina-ambers Oh also, we all suffer from impostor syndrome--that feeling that maybe we'll fail. I suffer from it at times. So have confidence in your ability to succeed in either option. Good luck with whatever you decide.

You're welcome.

Wouldn't that be nice! Thanks.

I'm glad you've found an approach that works for you! That's great.

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