Showing posts with label Scrum. Show all posts
Showing posts with label Scrum. Show all posts

Monday, October 7, 2019

Definition of Ready

While not part of the official Scrum Book, the Definition of ready can be a valuable asset for Agile Teams.
Over the years, we've seen stories being cancelled, deferred, incorrectly estimated and deemed incomplete causing a big frustration on development teams. Why? Excluding technical impediments or poor architectural decisions, a big problem could be on how the requirements were collected and transformed into a story. Other reasons could also be: incomplete or missing requirements and external unmet dependencies.
Given that all of the above contributes to wrong estimates and growing insatisfaction on development teams we'd like to share a template that could potentially be helpful for teams suffering from the above issues: a template for Definition of Ready.

Definition of Ready

The definition of ready (DOR) specifies the entry-criteria for an feature that is currently in in the backlog so that it's possible to work on it.  A Definition of Ready enables the team to specify pre-conditions that must be fulfilled before a story is estimated. The goal is of this document should be to provide a template that:
  • Helps the development team to properly estimate stories without inferring or discussing what features would look like during the estimation session.
  • Helps story writer to identify minimum requirements that should be addressed by addressing gaps and unknowns on stories that lead to rework, change of scope or disruptive changes
  • Provides clear requirements so that stories are better and more commonly understood by the team
  • Helps identifying and prevents problems early enough so they don’t surface after development starts
  • Reduces the time spent discussing stories. With clear requirements and dependencies met, the development team shouldn’t ask questions that potentially modify the scope and the size of the work
  • Identifies dependencies and impacts reducing risk

Requirements

We recommend the following requirements are satisfied to meet the definition of ready: 
  • The story provides a description, personas affected and clear acceptance criteria.
  • If the story requires front-end modifications, designs, mock ups, diagrams and explicit changes of any screens affected by the story are provided.
  • All external dependencies have been resolved and were documented.
  • If necessary, copies are written by the author. It helps decreasing external dependencies on stakeholders and helps building a shared knowledge by the team.
  • Necessary spikes were already addressed and no technical questions remain.
  • No business-related outstanding questions exist. They usually increase the scope of the story and invalidate the previous estimates.
  • We understand that for each story meeting the definition of ready, the development team can provide an estimate without neither going in too much detail nor skipping unmet dependencies/gaps in the contents of the story. With the estimate provided, the story can then be assigned to a sprint. We would also like to propose that the maximum size for stories is equivalent to half of the team’s velocity.

Checklist Template

The following table could also serve as a guideline to assert if the definition of ready is met.
Requirement
Y/N
Comments
The story has an objective description including who, what, why? Ex. Includes affected systems, objective screen names, urls, required data changes, etc?


The affected personas were listed?


The story has sufficient acceptance criteria?


If requiring front-end changes, were the copies provided?


If requiring front-end changes, were the wires provided?


Are there outstanding questions?


Were all the technical impediments (usually identified as Spikes or unknowns by the dev team) removed?


Are all the statements in alignment with each other (no conflicting statements)?


Is the vocabulary in use non-ambiguous?


Is the story potentially releasable?


Has the story dependencies on other stories? Which? Why?


Do you understand what business value the story provides?



The next sections will provide a better understanding on some of the above requirements.

Acceptance Criteria

While the purpose of this document is to help writing stories/requirements and acceptance criterias, the items below could also be relevant when writing acceptance criterias:
  1. What are the inputs and outputs?
  2. What changes are expected when the story is ready?
  3. Can you provide a list of high-level test cases related to the story that are understood by all team members?
  4. Not-expected: list of requirements, business rules, etc.
Expected format:
  • Be generic, in form of bullet points
  • Avoid duplicated, conflicting or ambiguous statements
  • Have at maximum, 6 requirements. We understand that more than that, potentially the story is too big.

Wires

Wires are very important for understanding, estimating and developing the story. I propose that all stories that require front-end modifications provide wires and copies before they can be estimated by the development team.

But not every requirement requires wires. As an example, these requirements that don’t require mockups:
  • Changes on the business logic on the backend
  • New jobs or changes in them
  • Email Copy changes
  • Changes on the database (patches, new columns without front-end requirements, etc)

Copies

If your team usually gets stories with copies like “Please insert your title here”, “Placeholder for copy”, etc. We recommend that the author of the story writes the copy for front-end and emails so that we don't rely on the business to provide them because:
  • changing copies on that last-minute forces tests to be redone and requires last minute builds, deployments and regressions that could be avoided.
  • depending on the business for providing the copy usually delays the start of the story by the development team
Providing the copies ahead of time will help developers to better estimate the story. Sometimes copies describe features the developers didn’t think of were they not provided.

Dependencies

As previously discussed, the team should ensure that external dependencies are met (except for copies). That includes business logic, external dependencies and potentially technical requirements. Unknown requirements, complexities and technical dependencies should be excluded from the estimates thus simplifying the discussions about the actual requirements and not on what they should be. In case there are unknowns, the team should reject the story proposing spikes or follow-up discussions.

Changes

Be noted that the objective of the Definition of Ready is not to create hard dependencies and roadblocks for the stories to be estimated. That said, it's expect that stories accommodate slight changes as it’s normal and expected that some refinement happens during development and we are open to them.

For the Development Team

In order to accommodate potential disruptive changes (see section Changes for more details) during the development of a story, I like to propose that the development team adheres to the following practices:
  • all stories are developed on a separate branch. That would protect the team in case either disruptive changes are required for a given story or if the development team cannot finish the story on time.
  • any significant disruptive change is evaluated and if big enough, the team will request that the story is removed from the sprint
  • spikes are created for the complex technical dependencies identified when discussing the stories
  • the maximum size for stories is equivalent to half of the team’s velocity
  • each story is treated as a potentially releasable feature

Conclusion

Remember that the Definition of Ready is not present on the official Scrum Book and is not part of Scrum. But, given how frequently team miss the deadlines, get invalid/incomplete requirements and struggle to understand the values of the stories, a definition of ready could be worth helping the team and the business to build a more robust framework that results in more satisfaction on both ends.

Check our Definition of Ready

As always, our Definition of Ready is available in our GitHub repo.

See Also

Monday, October 29, 2018

Tips for passing the PSD exam

Looking for help regarding Scrum.org PSD exam? Take a look at these tips
Not sure if you are aware but I'm a Certified Scrum Master. Back in 2014 I wanted to work as a Scrum Master but turns out I love to work with development so I never exercised that role. Lately however, I've been working on a project and realized that as a developer, I wanted to help my company to improve their Scrum. This time, instead of pursuing the PSM II, I decided to go for the Professional Scrum Developer certification.

The Professional Scrum Developer certification

But what is the Professional Scrum Developer certification (PSD)? According to Scrum.org:
Professional Scrum Developers are members of the Scrum Development Team and demonstrate knowledge and understanding of Scrum and their ability to build software using Scrum in real-world situations.  The value of certification is intimately tied to the demonstration of knowledge needed to achieve it. By that measure, the PSD assessment is significantly more valuable than available alternatives for Scrum.

Why you should consider the PSD exam

I think every developer that wants to work or works in an agile team should try to get this certificate. Why? Because most teams think they do Scrum right. My experience (as a contractor and employee) is that, it's rare to find a team that does scrum the right way and a company that respects and understands the Scrum framework.

And on the flip side, the certificate shows recruiters and co-workers that the developer studied, understands and knows the foundations of the Scrum framework validated by Scrum.org, managed by Ken Schwaber, one of the fathers of the Scrum framework.

What to Study

First, understand the Scrum Guide. This is the most important resource in Scrum. It may seem simple but you'll see how much each work in there makes sense (and makes a difference). Remember, Scrum is difficult to master. Second, especially for developers, study topics related to agile practices, Extreme Programming and how they apply to Scrum. It's amazing how many concepts were imported from XP for example into Scrum and people most people have no idea that they aren't required.

My suggestions are:
  • How to use scrum in a development project
  • Working within a Scrum Team
  • Why and how a Definition of Done is important
  • General development practices
  • Agile architecture practices to slice features
  • Test driven development
  • Agile requirement management practices
  • DevOps tools in Scrum
  • TDD, BDD, ATDD, CI, CD, Code Quality

Tips for passing the exam

Okay so let's take a look at some tips to pass the exam.

Tip 1: Read and understand well the Scrum Guide

The Scrum Guide is the most important document in the Scrum framework. You should read it multiple times carefully reflecting on each word. Understand well the Scrum Guide and the scrum foundations including the associated roles, events, artifacts, and rules. I suggest reading it 3 or 4 times before doing any assessment.

Tip 2: Practice with the Open Assessments

You should make exhaustive use of the Open Assessments. Basically they are a subset of the questions that you may encounter in the exam.  I suggest that you only move to the next step once you get constant 100% on all exams for at least 3 days.

Suggestion: after studying the Scrum Guide, do a couple of assessments. Validate each of your answer against the assessment answer and be sure to review it back on the Scrum Guide and understand the reason for that.

Tip 3: Explore related content

Once you understood well the concepts and the Scrum Guide, it's time to search for related resources on the web. A good start point is the Scrum.org web site:
Also try to find exercise questions and try them. My approach was before seeing the answer I tried to answer it in my mind to then, look at the response. It helped me memorizing and understanding better. However, don't trust all the answers that you see online. Be critical and reflect if the answer that you see (apart from those in the Open Assessments) is correct. I saw multiple errors around. Be critical!

Tip 4: Study developer-specific content

Apart from Scrum foundations, developers will find lots of technical questions. For developers, you can find on this page a lot of relevant information. The recommended bibliography is:

Tip 5: Exam Time

Okay so you prepared well, understood all the Scrum Guide and know the foundations of the related development questions you saw. How to deal with exam time?
  • Review a couple questions in the morning just so that information is reloaded in your mind
  • Take a few hours and go do something completely unrelated to the exam. Relax
  • Grab a coffee and start the exam.
  • Pay attention to the remaining time but don't be concerned. Time is enough. You have 60 minutes to answer 80 questions. Time is more than enough as the questions are usually small;
  • Don't waste too much time on each question. When in doubt, bookmark it and move to the next;
  • Use the bookmark feature - this is good to mark the questions you're not sure about and come back to them later
  • Remember: keep calm

Final Thoughts

Even if you don't consider taking the exam, just studying the Scrum Guide and doing the online assessments is a big step. It's common to see teams violating some of the foundations of the Scrum framework. The result is usually unsatisfied team members, lack of visibility and dysfunctional projects. Knowing what, why not reserve some time to review how's your understating of Scrum doing?

See Also

For more posts about Agile on this blog, please click here.

About the Author

Bruno Hildenbrand      
Sr Architect, Software Engineer and open-source enthusiast.
.NET, Azure, Go, Linux, Fedora, i3, Vim, Architecture, Docker & Kubernetes.