Відео

Perfect!

I understand how those similarities can be drawn. However, Job Stories and Acceptance Criteria serve different purposes. Job Stories focus on the situation, motivation, and expected outcome of a user's interaction with a system. Acceptance Criteria are specific conditions that must be met for a User Story, or Job Story, in order to be considered complete. While both add detail and context to the development process, Job Stories are about understanding the user's needs and motivations, whereas Acceptance Criteria are about defining specific requirements for completion.

@@MountainGoatSoftware thanks so much for taking the time to reply. I appreciate it

Thank you!

Story points are very much still relevant and useful. No one person gets to say they aren't. Their primary benefit is in allowing team members who produce work at different rates to agree on an estimate. A junior and senior dev will never agree on the time something will take. They can, however, agree that this thing will take twice as long as that thing. Story points estimate the size of the project. They can be converted to a release plan using velocity.

Feature is described around 4:00 in the video. I'm not familiar with "capability" other than in the generic sense of the word. If your tool is calling things, capabilities you'll need to use whatever definition the tool uses. This is why I don't like this overly complicated hierarchies.

I guess you could keep an epic open forever, but I don't see any usefulness to that. I'm thinking of Microsoft Word. They'll work on the spell checker forever. But there will be flurries of activity and inactivity (I assume). It would make sense to create an epic for a set of big changes to the spell checker. But I wouldn't leave it around just because we'll work on the spell checker again in a year or two. In personal to-do list software there is sometimes the distinction between projects and "areas of responsibility." Projects finish. Areas of responsibility are open forever. For example, I have a project in my to do system to travel to visit my dad next month. I'll do that and it will be done. I'll, of course, visit him again, probably in a couple of months. But I'll add that as a new projects complete with tasks like book flights, rental car, etc. In my to-do system I have an area of responsibility of "Finances" and it has all the tasks like pay my mortgage, my water bill, etc. That area of responsibility will be around as long as I am :) I think of epics more like the projects in this sense--they come and go.

@@MountainGoatSoftware thank you! I’m actually referring to a product rather than a project which has regular software enhancements from time to time (each sprint cycle). From the historical data, there’s not been any pause with the enhancements until to-date since the product went live. How shld you advise in this scenario? I have created 5 epics with a few stories tied to each epic, each sprint cycle the team has some enhancements to do since the product deployed is on MVP and we currently on day 2. When shld I close the epic since there’s always something to update each sprint cycle? Or Shld I close the epic w/ the stories then create another epic for software enhancements that’s open forever?

@@wennemenzo I don't think anything about my previous answer changes. I see no advantage to having some permanently open item on a product backlog.

Thanks. That really happened. GrubHub delivered to my neighbor. I only figured it out when they sent me a photo of the food in front of the wrong house. My neighbor ate it!

Someone will inevitably step into the Product Owner role (even if they don't have the formal title or if it's only temporarily). Someone has to decide what to work on next. I would suggest identifying who that person is and then working with them to become a formal Product Owner. If that's not possible, look towards the team for a temporary PO. Regardless of where your PO comes from, collaborate and communicate with them. Ensure that they're working closely with the team, providing feedback, helping the team understand priorities, etc. Then work to get training and support for that person who (is now) in the PO role.

Yes those are both correct to say. User stories will either be completed or they'll remain on the product backlog as a backlog item. Stories are progressively refined over time. Larger stories are broken down into smaller, more manageable stories as we learn more information. Sometimes you'll have a backlog item that's really big, in that case, a user story could be part of that backlog item. You're also correct in saying that not all backlog items are user stories. Some might be defects, like you said, but others could be different types of stories (like job or tech stories), straightforward tasks (like "Upgrade servers to latest version of Linux"), junk items ("homepage is missing title tag"), or large features.

@@MountainGoatSoftware super. Very helpful..thank you

I don't know what "Feature Planning" is so it's hard to comment. The test I use for good sprint planning is when a team can achieve the goal 60-80% of the time. If you're doing that, you're doing well. If not, see if there are improvements you can try.

I can't imagine a project for which I'd _recommend_ waterfall. But I don't want to rule it out for every project in the world if someone thinks it's right for them. (Still, I wouldn't do it.)

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.