Tag: scrum

Posted on

A wee bit of predictability math

Agile teams who start their Agile journey in Scrum quickly learn something called story pointing, and how to use it to enhance their predictability. (Hopefully they also learn to avoid trying to leverage story pointing to understand productivity, but that’s a separate story.) Anyway, there are many internet references to story pointing. Pointing is a clever way to avoid the need to make all the stories in our backlog roughly the same size prior to implementation.

When the team is also developing on a static cadence, say a “sprint” length of two weeks, then we can call out a set of stories, put them “in” our sprint backlog to be done in this sprint, add together their story points, and call that our forecast, say 40 points. It used to be called commitment and I still think that’s a good name: we commit to the Business that we’ll do everything we can to make our forecast. We can do that because we’ve established historical perspective that tells us we are consistently able to complete that many story points in every sprint. Jira (among many tools) shows us this in the Velocity Chart report.

Velocity, then, is about a forecast over a static time period. However Kanban teams are among those who don’t “sprint”; they don’t develop on cadence. They do demonstration and review on demand, and to establish predictable behavior they consider flow instead of velocity. They have more work to do on their stories: instead of pointing them, a Kanban team needs to split their stories until all the stories they develop and deliver are about the same size. When that is true and if we are on a cadence, we could switch our units of velocity from story points per sprint to stories per sprint and it wouldn’t matter much. When we are not on a cadence as on a Kanban team, we think about flow instead, or the average time to complete a story once it is selected for development; this is called Cycle time. (Separately we can have a discussion about the related measure, Lead time.) Note that Cycle time and Velocity are inversely proportional to each other if both are being measured with the same units (either stories, or story points). Example using stories:

Let Velocity be the average stories per sprint
Let Flow be average days to complete a story
then Velocity = L / Flow
where L = sprint length in days

If we are using story points rather than stories, and not trying to get all our stories to be about the same size, Jira only helps us if we are on cadence, ie sprinting. Jira does not measure cycle time for story points, only for stories, so a story point-based cycle time must be calculated manually. That being the case, we discourage story pointing unless our squad is sprinting. Instead we encourage splitting our stories until all the stories we select for development are of similar size.

Cadence, such as the sprints in Scrum, is very useful. Teams typically thrive on the rhythm and story pointing is not difficult (at least, not once you “get it” – yet another separate story!). Kanban teams have more flexibility but as is so often the case, it’s a trade off: more discipline in story splitting is needed to be successful.

Posted on

Scrum Cookbook

Scrum is easy! No really, it is. Doing Scrum well is quite difficult, but doing anything well usually takes thought and practice. We can start right in though. First, read the Scrum Guide at scrumguides.org . Second … follow my cookbook! Now laugh, because of course it is not quite that easy (and you can tell that because this is not a short post!), but once you have received training this cookbook may be a resource you and your Agile Coach can use to jumpstart your transformation to execution using an Agile paradigm.

Scrum can be used to quickly lead a team to the Agile Minimum Viable Product (to paraphrase Mike Cottmeyer): that MVP is (1) a genuine, collaborative team, (2) a single-source product backlog, and (3) frequently executing stuff. If you have these three items and you have a continuous improvement mindset, you’re genuinely getting close to Agile.

Ok, so have you read the Scrum Guide? No? Go do that, I’ll wait. Now let’s get started. Please let me know if you have any comments or questions.

Preface: Recently Scrum and Agile have been moving away from the use of the word ceremony, choosing instead to call them events. It is important that we stay away from the word meeting, because that means a gathering that is not in scope for core work, whereas a ceremony or event is intended to be exactly that. In this paper I’m going to stay with ceremony because it seems to stand out a bit more, but the Scrum Guide calls them Events.

Communications Guidelines

The following are suggestions for enhancing communications and collaboration, especially intra-team, particularly when there is involvement in multiple geographies. A multiple geographies situation is highly discouraged, but we are finding that they’re unavoidable. What I mean by this is most clients of Agile Coaches don’t respond well to the suggestion of colocation unless they already have it; they’ve invested (sunk) too much into distribution and emotionally they can’t just let go. (The admonition to ignore sunk costs usually does not help as much as you would like.) If the Coach insists, they usually throw out the Coach and s/he has no opportunity to help. I conclude that moving to colocation must wait for a substantially higher trust profile, must be very gradual, and must be initiated while armed with a client-specific, well-researched business case. Meanwhile, if we add just a bit of discipline in a few communications areas it can greatly assist us in communications precision and bandwidth, which in turn facilitates real collaboration.

  • Any time you are planning to communicate with someone where there is a higher risk of misunderstanding, and in advance if possible, draw a picture of the information you plan to communicate and socialize it.
  • Any time you are talking about a Jira (or Rally, or whatever your favorite work manager is, here I’ll use Jira) issue or ticket, try to begin the conversation by clarifying which one you’re talking about, by number. For example, TEAM-12.
  • No email – none. Email is transient, suitable for sending someone a gentle reminder, but otherwise, all information should be in a Jira ticket, or Sharepoint location, or Jive or Confluence location (below I’ll use Confluence), or Slack/Symphony channel (below I’ll use Slack) – whatever your collaboration environment gives you access to. You don’t have tools like these? Get them. Or colocate. Your client must make at least some investment in seamless communication and collaboration.
  • ANY information about a ticket in Jira should be either in that ticket, or referenced explicitly in that ticket. A ticket/work item is about work, so ensure that the results from the work – generally artifacts and deliverables – are obvious, or referenced in the ticket.

Socialization, Team Norms and Continuous Improvement

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master
  • Required Attendees: Entire team, including Product Owner
  • Frequency: on team startup, and whenever changes to the Team Norms are needed
  • Duration: As long as it takes. The whole team dynamic is based on trust and common understanding of how we will behave toward each other.

The following is suggested. 

  1. Certain basics must be followed by the team and therefore agreed on by the whole team. This isn’t a Scrum ceremony but treat it as such, because this is fundamental to continuous improvement.
  2. On the team’s Jive page, or Sharepoint page, or the team’s persistent and highly visible repository of choice, plan to reference, and then develop and maintain, live documents briefly declaring the following items. The scrum master should invoke these items frequently to ensure consistency and high performance. They can be changed in any retrospective by the team to experiment and look for performance improvements. The team trusts each other to follow these team norms.
  3. Team name, purpose and mission
  4. Team’s Agile metrics and Business KPIs, the business level measures the team is growing for the business or organization.
  5. The product(s) for which the team is responsible, and a vision statement, roadmap outline and product architecture for each product. Geoffrey Moore’s elevator pitch is a reasonable place to start in preparing a product vision statement. A roadmap should be high level, lots of detail is probably wasted effort due to reprioritization over time. Architecture is any guidelines, patterns and constraints to be used in governing development and delivery of the product.
  6. Team’s Definition of Ready (DOR) and Definition of Done (DOD) for work items (usually user stories) that can be in a sprint. Briefly, the DOR lists the properties of a work item that must be true for it to enter a sprint. The DOD lists the properties of a work item that must be true to consider it done and be included in the actual capacity (velocity) for the team. Plenty of sample definitions exist online.

Ceremony: Daily Stand-up or Scrum

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master (initially – note that not only can anyone can facilitate a daily Scrum, but surely there will come a day soon where the Scrum Master is unavailable to facilitate) 
  • Required Attendees: Entire team, including Product Owner
  • Frequency: daily, hopefully at the same time every day
  • Duration: 15 minutes plus optional 15 minutes (or more, as team agrees)
  • Other notes: (1) recommend being strict on starting on-time, (2) if you mention a Jira ticket, include the ticket number so people can track things

The following script is suggested. 

  1. Begin: Scrum Master or facilitator begins the meeting exactly at the appointed time, or at most 1 minute late. Stragglers will quickly learn that the meeting started without them, and that others’ time should be respected. If some are routinely and unavoidably detained, then maybe a slightly different start time should be agreed on.
  2. Intro: Scrum Master introduces the meeting: This is the daily stand up for the <team name or description>. As you know, generally we stand to ensure that the meeting stays short.
  3. Announcements: S/he makes any absolutely necessary announcements. If there are more than about 2, then they should be written out and referred to instead of explicitly announced. If they don’t belong anywhere else, they can go into the meeting notes (e.g. in Confluence), or Slack, whichever is appropriate.
  4. Script: The Scrum Master scripts the meeting for today (do this each time, it is important):  I invite each of you to let us know what you did in the past 24 hours, your plans for the next 24 hours, and any frictions slowing down or impeding you or the team. Generally, please focus on collaboration. Be sure to note any people you’d like to get together and work with today or soon. We will finish this meeting within 15 minutes. We’ll offer the next 15 minute interval as a “16th minute” for anyone who would like to stay and collaborate after the official ceremony, but that is optional. Who would like to go first? Note the invitation. Let the team set the order for who speaks. Another algorithm is to ask a speaker to nominate a successor; there are several good algorithms, perhaps you can mix them up.
  5. Participants: As the Scrum Master records input into Confluence, we proceed in random order by who steps up to go next until the team members have all contributed – what I did yesterday – what I plan to do today – things slowing me down; focus on collaboration.
  6. Actions and Collaborations: Scrum Master lists actions and assigns a responsible party to each. Scrum Master lists collaborations requested and ensures that there is an agreement on both sides that they will meet.
  7. Adjournment: Scrum Master adjourns the “first 15 minutes”, the actual daily stand up.
  8. 16th Minute: Scrum Master announces, we’re now on the “16th Minute” for anyone who would like to use this time for further collaboration. It will last until <time>. I’ll stay as long as I can facilitate or otherwise be useful. The floor is open.

Ceremony: Backlog Refinement (including sizing)

  • Responsible Party: Product Owner
  • Sometimes called: Backlog Grooming (deprecated) or Story Time
  • Facilitator: Scrum Master or Product Owner
  • Required Attendees: Entire team, including Product Owner
  • Optional Attendees: team representatives from teams with strong dependencies
  • Frequency and Duration: Technically this is not even a Scrum Guide ceremony; the Scrum Guide does insist, however, on frequent performance of this activity. We recommend that a collection of 1 hour (absolute max 90 minutes) sessions be established in a rhythm and total duration such that Sprint Planning (when done without “tasking”) takes no more than 45 minutes. 
  • When: anywhere in a sprint; note that the information to be covered is relevant primarily to the next sprint. Again, establish a rhythm.
  • Other notes: (1) recommend being strict on starting on-time, (2) if you mention a Jira ticket, include the ticket number so people can track things
  • Required Preparation: DOR/Definition of Ready is ready; this is an agreed on team definition of what properties a Jira ticket must have in order to be eligible for inclusion in a sprint. Product Owner has submitted into Jira any requirements – mostly user stories – that are needed (it is ok if s/he puts in a few more, but not a lot more, during this meeting) and that most of these are roughly prioritized (“MoSCoW”)
  • Optional Preparation: even though Jira is in use, many teams ask that the Jira tickets to be considered be placed onto 3×5 cards or sticky notes for tactile use if the meeting will be held entirely in the same room. This can be a fair bit of work but can be very worthwhile. Product Owner is responsible for this.

Definition: MoSCoW: this means to prioritize using this pattern (more here):

  • M – MUST have
  • S – SHOULD have, if at all possible
  • C – COULD have, if it does not affect anything else
  • W – WON’T have this time, but would like in the future

Sizing: means to size the requirement. A Wideband Delphi, and therefore consensus-based and relative, effort sizing method called Planning Poker generally should be used. There is lots online on Planning Poker, but here are some of my thoughts:

  1. Introduction to sizing: we recommend this script to be read each time sizing is performed: When we are sizing today, be reminded that our goal is not productivity but predictability. Please keep any thoughts of time to yourself, e.g. no mention of words like days or hours. Size relative to our baseline story (be sure to identify the story). Avoid sizing aloud to eliminate biasing; use the planitpoker. If you’re in a meeting room try using a phone app. In turn, the facilitator will try to ensure that everyone has voted before the reveal.
  2. If needed, baseline sizing with a baseline story – a first story (8 points) or a small (as perceived) story (1 or 2 or 3 points). That story becomes your baseline story. The previous sentence leaves quite a bit of flexibility; the initial recommendation is that teams start with a baseline small story that is designated as a 1 point story for comparison purposes.
  3. Discuss top story on the backlog (after all, its priority is highest, from the refinement that has already been done) – PO leads
  4. ALL team members pick their estimate face down or virtual face down. The PO may participate as the team decides, but stay consistent on this; the Scrum Master should not participate, only observe. The principle is: only if you are doing development work should you participate in sizing; after all, it is that work itself that you are estimating.
  5. Show estimates once everyone has committed to a sizing
  6. Explore largest/smallest
  7. Repeat until team agrees on size for the requirement

To perform sizing across several geographies, try planitpoker.com . To perform sizing including several people in a single conference room, try one of the phones apps listed here in my blog entry on the topic.

The following meeting script is suggested.

  1. Scrum Master opens the meeting, declaring its purpose, its time box (ending time), and ensuring that all required attendees are present, in particular the PO and PM. Scrum Master should state the best understanding of the team’s current user story velocity.
  2. DOR: the Product Owner is invited to review the Definition of Ready. This should be reviewed every time.
  3. More? Scrum Master asks if any requirements need to go into the backlog; those from the PO are automatically inserted. Those from others are considered by the PO, who should let them in unless there is a very clear reason not to (e.g. it’s a duplicate).
  4. Scrum Master asks whether there are any requirements that have not been at least roughly prioritizedalready; such requirements are immediately prioritized with MoSCoW. The PO performs this prioritization while s/he is watched by everyone. Anyone can supply input to the PO during this, however the idea is to get this done quickly. If there is lots of argument, just do what the PO is suggesting and move on.
  5. Scrum Master asks for rank prioritization. Product Owner leads this. S/he rank orders the Must Haves, topmost, then next, then next, etc. All discussion is welcome, but again the idea is to be brief. If there is lots of argument over placement of a requirement, put it where the PO wants to put it and move on.
  6. Scrum Master asks for sizing. See above. Take the top requirement. Product Owner briefly describes it. Team sizes the requirement. Repeat until the Must Haves are exhausted. 
  7. Scrum Master asks for splitting. Knowing the team’s velocity, and starting at the top of the rank ordering, split any stories that should be split. The Product Owner leads this. Each resulting story should be roughly prioritized, rank ordered and sized by the team as you go.
  8. If there is time, the Scrum Master can invite discussion of the Should Haves to determine if any of them actually are Must Haves, in which case they are rank ordered as before and sized by the team as before.
  9. When you run out of time, so be it. If you need more backlog refinement, the Scrum Master facilitates getting it scheduled.

Ceremony: Sprint Planning

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master and/or Product Owner
  • Required Attendees: Entire team, including Product Owner
  • Frequency: on the first day of each sprint or as soon as possible thereafter
  • Duration: until it’s done; schedule an hour and try to be done early … ok, perhaps your first time schedule 2 hours and try to be done early

Here is a suggested script:

  1. Scrum Master ensures that the following information is conveyed: the sprint, its dates, the current vision, current roadmap, current release features, development status, architecture, previous sprints highlights as needed. This needs to be quick, but it all must be covered, every time.
  2. Show the velocity in prior sprints, preferably from a Jira-based information radiator. Team then comes to agreement on new velocity.
  3. For each team member, determine availability and resulting capacity in story points (there’s some math here for which a spreadsheet often proves convenient)
  4. Review the Definition of Done
  5. Review other definitions as needed
  6. Product Backlog review by PO, and select user stories that can be completed in sprint
  7. If user stories must be tasked, then this is the place to do it. This is a significant topic and we do not go into it at all here, other than to say we recommend that a team new to Scrum and User Stories begin by doing no tasking and see if they can make it work with nothing more than informal and frequent collaboration instead.
  8. Challenges, dependencies and risks
  9. Review capacity required, risks and mitigations, and ask for …
  10. A Commit to the forecast! (use a fist of five)
  11. Parking lot and actions
  12. Any quick plusses and deltas as a quick retrospective on the meeting

Ceremony: Sprint Review and Demonstration

It’s simple: at the end of each sprint, review your software (or systems, whatever it is that has been developed). This must include an objective demonstration of the software, a real demo; though it need not be formal it must be a real demo.

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master; not the Product Owner, as the Product Owner should focus on the Product, and receiving and approving work done as meeting stakeholder needs
  • Required Attendees: Entire team, including PO; any interested stakeholders; as many clients and/or client proxies as you can find
  • Frequency: near or at the end of each sprint
  • Duration: as long as it takes with a preference for shorter
  • Notes: many use Jira for this exercise: each user story is demonstrated in turn. Reminder: it’s not justa demo, it’s a review of what has been developed. The demo is your objective demonstration that what we say has been done, has been done.
  • Introduction: the ceremony can start with this: This is the Sprint Review. Its purpose is to review our product as it has been refined over the last two weeks, and demonstrate what we have done to our stakeholders to obtain their feedback. This is our objective demonstration that what we believe we’ve completed is done to the satisfaction of our stakeholders. In general we’ll go through the Jira items one at a time in priority order, per the script we’ve been preparing over the last few days.

Ceremony: Retrospective

At the end of each sprint, review your process.

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master
  • Required Attendees: Entire team, including Product Owner
  • Frequency: at the end of each sprint; optional: every other sprint
  • Duration: 1 hour

Suggested script: 

  1. Introduction, including the ceremony stop time. Here is a good script for the introduction that includes Norm Kerth’s prime directive: This is our retrospective, where we evaluate and experiment with our development and delivery process with intent to improve. Regardless of what we discover today, we understand and truly believe that everyone did the best job s/he could, given what was known at the time, his/her skills and abilities, the resources available, and the situation at hand. Our purpose here is continuous improvement, to become more skilled and higher performing as a team over time. We will end this session at ____.
  2. A framework is set up for the retrospective. There are many available, for example search for “10 retrospective styles” online. Here is one often used early on: Scrum Master asks for each person attending 
    1. to write down 3 things that went well
    2. to write down 3 things that could use improvement
    3. to prioritize each set

Stickies can be used if everyone is in the same room – one item per sticky note.

  • Each person articulates to the group attending their top went-well item – skipping those already covered
  • Ditto improvement suggestions
  • Scrum Master records actions as we go
  • Suggestions for improvement are prioritized
  • Each is placed into a Process Improvement Backlog
  • The Scrum Master ensures that the top two are assigned volunteer owners in Jira
Posted on

Link Library – stuff I recommend on the www

For a long time I maintained a web page. It’s still there (www.densmore.org) but I just don’t use it for a whole lot anymore. Maybe I should link from there to here – I just might do that. Meanwhile, I do occasionally like to keep a link, or recommend a link, on a variety of subjects. Most of my links should be thought of as starting points – there’s always more to learn. So that’s the purpose of this post. If I do as I just promised myself I’ll update this when I find new stuff … and even occasionally test the thing to be sure a previously installed link still works.

Subjects you’ll find below, should you choose to you scroll down: Agile, Distribution, …

Subject: Agile and Agile Frameworks and Methods

Subject: Distribution or non-colocation or we’re all in different places