Build-your-own Sprint Planning Canvas!

You know, the Business Model Canvas, the Empathy Map, the Product Canvas: They all have one thing in common: Stacking up all the useful questions into one piece of paper, printable starting at A3 (or larger). Guiding the users through the nescesarry steps towards Awesomeness. (To be honest, if I would have had this brainwave before we started the meeting, it probably would have been a lot more easy to go through the process.)

So here it is, the current version of our Sprint Planning Canvas. As a team, we are still tweaking it to ask us all the right questions we need, so this is only the 0.3 version… But it’s good enough to give you an impression.

Find the complete post here: https://www.linkedin.com/pulse/build-your-own-sprint-planning-canvas-something-inspire-jaap-mintjes/

Working with Stakeholders Who Won’t Take No for an Answer

Sign up to receive weekly tips like the one below from Mike Cohn to Help You Succeed with Agile here: https://www.mountaingoatsoftware.com/email-tips

Do your stakeholders have a hard time accepting a “no” from the team? Or put another way, does your team have a hard time telling the stakeholders that what they want is impossible? If the answer to either of those questions is yes, you are not alone.

I’ve found two techniques useful in communicating a “no” so that stakeholders listen and understand.

First, the team should establish a track record of planning projects accurately and meeting most commitments.

You don’t need to be perfect, but if a team meets most of its commitments, the business is more likely to listen when the team says something is impossible.

Second, when telling a stakeholder that a proposed date cannot be achieved, offer alternatives. For example,

  • By what date could the functionality be delivered?
  • Are there especially challenging requirements that could be relaxed to meet the deadline?
  • What could be done to make the date feasible? More people? Stop using the team for second-level support?

Stakeholders often want more than can be delivered by some date. This shouldn’t be the team’s problem alone.

Wanting more than can be delivered must be viewed as a shared problem. A solution can only be found by the business and team working together.

When stakeholders trust the team’s commitment and work together with team members to find solutions, they all succeed with agile.

Why Agile Teams Should Estimate at Two Different Levels

It is very common for agile teams, especially Scrum teams, to estimate both their product backlog and sprint backlogs. In this article, Mike Cohn will address:

  • Why estimating both the product backlog and sprint backlog can be useful even though it seems redundant
  • Why teams should estimate the two backlogs in different units
  • When teams should estimate
  • Whether all teams should estimate

Although I think you should not try to use hours for estimation, I agree using different valuations for an estimation is best. I find using T-shirt sizes for PBIs and Story Points for SBIs work well.

Read the complete article here, and also take note of some excellent comments at the bottom: https://www.mountaingoatsoftware.com/blog/why-agile-teams-should-estimate-at-two-different-levels