Advanced Topics In Scrum

1. Yes, It’s their process why not?
2. No, explain to them and work through why the retrospective is so important.
3. Maybe, if they are no longer a team then why continue with Scrum?
4. Only do retrospectives once a quarter and build up a good list of things to change.
5. Yes, the process will take care of itself we don’t need to watch it that closely. After all, it’s common sense!

Comment: Of things to watch out for and not allow this is high on my  list.  It boils down to this rule: If the team is not doing a retrospective then they are not doing scrum. The retrospective is where the team takes formal ownership of their process. In these situations I crack shins, and kick knee caps and generally do what is necessary to ensure they continue doing a retrospective. Without that we often see teams fall into “it’s not my fault”  because “x” told me to. In some cases “x” is the process that no-one owns, imagine the process that gets created by someone who decides to own it but, does not do it themselves!.

Retrospective is an external constraint that must be demanded of the team. There are many ways to run a good retrospective, ScrumMaster rise to the challenge and support your team.

1. We have consumed all the work we said we would in our sprint planning
2. All of the work has been completed.
3. Both the team and the product owner agree it should end.
4. The amount of time specified for the sprint has run out

Comment: The conversation here is about setting a time-box and sticking to it. Failing to adhere to the time boxes for your sprint is a bad habit. Without time-boxes we rapidly loose our sense of predictability and the amount of complexity we tackle in each bite drifts upward. Teams become fragmented and loose cohesion.

When would you not time box your sprint?

Hi Folks,

Attached is our latest chapter Scrum In A Nutshell.

This version is baked and we would love your feedback.

Please download and read.

1. Sure, thats what agile/scrum is all about.
2. Sure, you might wonder if you are making things harder to detect.
3. No way !!!

Comment: The idea here is that there can be only one source for Scrum knowledge. I guess that depends on where you get your definition from and what you need. Should there be only one way to think about scrum? Probably not, although,  a rookie mistake is to modify without have deep applied practice and experience under your belt. The 1st common mistake we see people make is modifying scrum without understanding it. They often confuse themselves and their organization.

There is another method that has gained in popularity and that is Kanban.

In this chapter we explore how it applies to Scrum.

How it scales?
Where the difficulties are?
etc.

Please read and comment.

Thank you
- Dan and Doug

This is my first attempt at making a Livestream cast with Video. The talk is on Scrum and is really a primer or refresh of what Scrum is. There will be several more videos coming that will start to make up a knowledge track that you can follow through.

I hope you enjoy. Please leave a comment on your experience.

Look for more videos coming soon from a wide audience of practitioners, coaches and trainers.

First of all, let’s talk about capabilities. Basically, a capability is something that a stakeholder has asked for; and it is something that provides value for that stakeholder. When it comes to be software products were building, these things are often called features, as well.

Capabilities are the things we talk about with our stakeholders, and we talk about them in the stakeholder’s language. Strictly speaking, capabilities are seldom of concern to the development team, as the developers will be working on stories, which we’ll discuss later in this chapter. Capabilities far too often too big, hard to validate chucks of work, so it is not something we want to feed our team directly as an item of work. The reason is simple, large chunks or difficult to validate chunks of work lead to elongated feedback cycles and this is what got us into trouble in the first place.

Our development is being done to acquire those capabilities for the stakeholders, and therefore we must be able to talk about capabilities with our stakeholders. Capabilities are the language the stakeholders are thinking in and it’s is what they will use to understand the product we have built.

As we know, stakeholders can ask for virtually anything. Therefore, capabilities can be virtually anything, from small bugs that he be fixed to extremely large wishes and dreams. For example, each of the following statements describes a capability:

• Remove the extra linefeeds in the presentation of the list of flights on the “Choose a Flight” page (a bug);
• I want to be able specify that I need a special meal for my flight (a new feature); and
• Make it faster (an extremely large, ambiguous request).

What’s important to know about capabilities is that the priorities of the capabilities derived from the stakeholders, even though they may be modified by dependencies that the developers see. Since scrum is all about having a prioritized list of things to work on, we can see that most of the priorities that we derive from the stakeholders.

What we are usually trying to deliver in a release is a releasable capability. This leads to concepts that we find in the literature such as Minimal Marketable Feature (MMF), Minimal Releasable Feature (MRF), and so on. Even though I won’t discuss it, I think that for scrum what we really need to produce is Minimal Demonstrable Features (MDF), as the basic concept of scrum is to inspect and adapt, so we need to produce capabilities that we can demonstrate in order to get feedback.

The purpose of scrum is to develop product, often software and other ancillary products based on items in the backlog. In order to talk about this work we use lots of different terms when talking about backlog items, such as capability, feature, story, task, and so on. In this chapter we will define the terms that we use in this book, and have some discussion about the differences and nuances.

In particular, we will discuss the following terms: capability, chore, story, epic, and task. There tend to be natural comparisons and pairings in this set; for example, capability versus chore, stories versus epic, and story versus task. Each of these issues will be discussed as we go along.

But first, a quick review of fully know about Backlog Items, or PBIs. Basically a backlog items is anything the lives on the backlog; it can represent work to be done, issues to be discussed, or problems that we have. In any case, a backlog items is a token for future conversations, that progress from the moment we know about the backlog item until the work it represents has either been completed or discarded.

Tasks are the actual units of work the team does when working on a story in a sprint. The story is the item of planning and negotiation, but team often break stories into tasks in order to manage their work. We will seldom discuss tasks in this book, as the internal workings of the scrum team aren’t this book’s main focus.

The tasks for a story are “owned” by the team; the team commits to stories, not tasks. The tasks only exist to aid the team in its development efforts – it is the “doneness” criteria that define the “contract” for the story, not the tasks. Generally speaking, it is nobody’s concern except the team’s who works on what task, or even what the tasks are.

Another major topic for discussion here is the Epic, which many think is just a “large story.” However, I like to define epic as an item that can’t be committed to by the team. This could be for a variety of reasons, most of which are captured in the acronym CURB:

In any case, an epic is an item that contains at least one story, even if the story is just an investigatory one. Usually, an epic contains analysis stories that produce other stories that also belong to the epic. In other words, an epic is a container of stories, and we tend to refer to any container of stories as an epic.

Since an epic becomes an epic if the team can’t commit to it, sometimes we are surprised when an item we thought was a story turns out to be an epic during planning; we only find out when the team declines to commit. This is not unusual, because we can’t know whether or not we can commit for sure until we know what “done” means for the item.

Most capabilities are epics rather than stories; the main counterexamples being bugs or trivial features. If we think of a use case as being a typical capability for our software, then it is an epic, with the individual scenarios of the use case being potential stories. Of course, some of them might actually be big enough to be epics of their own.

Some examples of epics are:

•        “We want the system to be able to manage the pilots’ schedules”;

•        “We’re going to need to train all our users on this new release”;

•        “As a <tourist>, I want to <fly to Catalina for the weekend>”; or

•        “I need you to translate the website to Spanish, because I’m planning to do a lot of marketing of Catalina Air in Mexico”.