Team Skills Assessment

My team’s DONEness definition is aligned with other teams on the same product

I know what other teams are working on and how their work relates to my teams’ work.

I find out what other teams on my product are doing when something breaks or has to be redone.

Release goals are communicated to the Development Teams without our input.

Release goals are set realistically; based on team capability and capacity.

I look for opportunities to expand my skill set in ways that supports my team’s success.

I feel that if someone can’t do the job its not my job to help them learn how.

If someone on my team needs help I help only if I have time and know what to do.

My team mates regularly check to see if anyone needs help.

Team members are assigned PBIs and work independently.

I work side-by-side (in-person or virtually) with my teammates.

I work by myself checking in with the team as needed.

Its best if the best person for a task works on that task.

Work on my team passes from person to person depending on the skills needed.

People on my team frequently don’t have enough to do because they are waiting on other team members.

Work is handed off from one person to another on its way to getting done.

My team’s Sprint Reviews include an evaluation of the product and what we need to do to stay on schedule.

It is easy to identify when a product backlog item was originally created for the customer.

My team works on product backlog items that are more than two years old.

The output of my team’s Sprints works and is production quality; even if not yet valuable enough for the customer.

My team does not work on product backlog items that are not clearly and completely defined.

My team is OK working on a product backlog item that we don’t completely understand.

My team works with the product owner to trade off functionality for schedule.

My teams finds that Sprint Goals make a big difference keeping the team focused.

My team uses Daily Scrums to ensure that we are always tracking toward the Sprint Goal.

My team uses Sprint Goals with every Sprint

My teams product goals are reviewed and updated in Sprint Review.

My team plans only what we know we can complete in a Sprint.

My team has more than one product backlog item left incomplete by the end of the Sprint.

If a work item cannot be done for reasons beyond our control; we renegotiate the iteration content with the product owner.

My team finishes everything they planned in Sprint Planning.

My team shortens or lengthens Sprints when necessary.

My team lengthens Sprints when necessary.

The team creates a Sprint Goal at Sprint Planning.

The team celebrates successful Sprints and successful goal achievement.

Team members help each other out frequently.

The team is focused on getting everything done that we planned into the Sprint.

My team creates a comprehensive sprint plan during Sprint Planning.

During Sprint Planning my team identifies risks and potential blocks and creates plans to mitigate them.

My team uses Sprint Planning primarily to identify which backlog items will be completed during the Sprint.

My team’s Sprint Planning events don’t run longer than one hour.

During Sprint Planning my team identifies how vacations and holidays might effect the Sprint.

During Sprint Planning my team identifies who owns each product backlog item included in the Sprint.

My team’s Sprint Reviews consist of a review of metrics for the Sprint.

Each sprint contains something from the previous retrospective to help my team improve our outcomes.

As long as we are getting the job done; management is happy.

Retrospective plans are dropped in order to get more work done in the Sprint.

My team’s Sprint Retrospectives provide one or two action plans for improvement.

The team is always looking for ways to get more done in a Sprint.

My team’s improvement actions are tied to metrics that easily tell us how we are doing.

My team has plans to improve; but we have no idea how effective those plans have been.

The documentation my team creates is absolutely necessary

My team creates only the documentation that is needed.

My team creates a lot of documentation that isn’t used by anyone.

My team usually has more than five PBIs in progress at the same time.

My product owner understands the market in which our product is sold.

My product owner has no special knowledge of the customers or market my team serves.

Our product owner does a good job of managing relationships with the stakeholders.

Stakeholders are not invited to my team’s Sprint Review events.

My product owner checks in with me at least once a day.

I don’t see my product owner during the day.

My product owner is available to me every day.

I never have to wait more than a few hours to ask my product owner a question.

My product owner always discusses functionality in terms of the user and what the user needs to accomplish.

My team has little useful information about our users.

My team runs experiments whenever the right solution is not immediately obvious.

When my team makes a mistake; we correct it and then figure out how to keep it from happening again.

When my team makes a mistake; we tend to keep it to ourselves and solve it before anyone finds out.

I feel that management does not tolerate mistakes.

If a work item cannot be completed because of a mistake by the team; we are expected to do our best and take steps to ensure that the problem can’t reoccur.

I feel encouraged to speak up when something could be improved.

Pointing out why a process doesn’t work gets you yelled at by management

My thoughts on how to improve a process or procedure is eagerly heard by my team.

I feel encouraged to try new things even if I make little mistakes along the way.

I have no problems asking questions when I don’t know how to do something.

I will be made to feel foolish if I suggest something that can’t or shouldn’t be done.

I don’t enjoy working with my team mates; they tend to be angry and short tempered with me.

Everyone on my team is willing to help me when I ask.

Senior members of my team are always willing to help the more inexperienced team members.

I can speak openly with other employees and they feel comfortable being open with me.

Management treats my teammates and me fairly.

Everyone on my team is treated fairly.

It is often held against you if you make a mistake on this team.

Members of this team are able to bring up problems and tough issues.

People on this team sometimes reject others for being different.

It is safe to take a risk on this team.

No one on this team would deliberately act in a way that undermines my efforts.

Management supports my team by providing tools resources and advice.”

My team avoids debates about solutions; they just turn angry and loud.

My team calmly; fairly; and professionally debates potential solutions.

I feel encouraged to try to identify opportunities for innovation

Innovation is expected to come from management; my team does as we are told.

Processes exist for a reason; my job is to follow them.

My team encourages unusual ideas and suggestions to see what can be learned from the discussion.

I feel valued by my team and supervisor as an important member of the team.

My ideas are valued by my team and my supervisor.

Titles don’t mean anything on my team.

The higher your title the more respectfully you are treated by others.

Working with members of this team; my unique skills and talents are valued and utilized.

My team has a DONEness definition.

My team uses our DONEness definition during Sprint Planning and throughout the Sprint and checks it during Review.

My team’s DONEness definition is routinely reviewed and updated.

Product backlog items are either DONE or NOT DONE by the end of the Sprint; we don’t discuss “almost” DONE.

My team splits unfinished product backlog items into the done and not done portions at the end of the Sprint.

My team holds Backlog Refinement events during the Sprint.

When my team slices a backlog item into smaller pieces each piece is clearly demonstrable by the end of the Sprint.

During Sprint Reviews my team demonstrates only product backlog items that we deem DONE.

Work is often added during the sprint when the developers are asked to do something we hadn’t planned to do.

Standards exist for what I do and they are carefully followed.

Artifacts aren’t checked in until tests (or other inspections) are completed and successful.

Features are not considered complete unless all of their tests run successfully.

My team has 10 or fewer developers on the team

My team has at least 3 members on the development team

During Sprint Planning my team figures out how we plan to work together to complete the forecasted work.

My team has a voice in selecting new members.

My team has a voice in removing team members who aren’t working out.

My team determines our iteration length.

My team changes iteration length when necessary.

My team uses pairing (pair programming; pair testing; etc.)

My team uses test-driven development (tdd)

My team does code reviews

My team writes automated unit tests.

My team writes automated acceptance tests.

My team runs tests continuously.

Management communicates clear organizational goals and how my team is expected to contribute to those goals.

It is difficult to ask other members of this team for help.

My team can holds calm debate about solutions when we disagree. We usually find a good compromise solution.

My team just does a product demonstration during the Sprint Review and then we move on to the Retrospective.

A core group from my team does the Sprint Planning.

A core group from my team does the backlog slicing.

During Sprint Reviews my team demonstrates in an environment (nearly) identical to a customer environment.

When a defect is found it becomes my team’s number one priority to correct it.

Defects are addressed and corrected during the Sprint in which they are found.

My team has times during the week in which no emails; text messages; or meetings are permitted.

Tasks often take longer than they should because of unexpected interruptions.

The development team estimates all work items that they are expected to build.

My team achieves at least 80% code coverage with our automated tests.

My team does regular refactoring of our code.

My team uses Sprint Planning for the product owner to tell us what we are going to build this Sprint.

Our product is rebuilt and retested at least once a day.

My team builds high value work before bothering with low value work.

My team does not build low value work until nearly all of the high value work is done.

Everyone on my team plays one and only one role (Scrum Master; product owner; Development Team Member)

Requirements are best communicated through documentation.

My team discusses requirements thoroughly before determining a solution.

The Development Team considers multiple solutions and then decides upon the best solution under the current circumstances.

My team does not have the skills that they need to get the job done.

If the product owner asks for a change to the work item; the Development Team members knows that they can decline if the Sprint goal could be affected.

My product owner determines the value of new items during refinement and reprioritizes appropriately.

My team slices large product backlog items into the types of work we have to do (e.g. coding and documentation)

During Sprint Review incomplete product backlog items go back to the Product Backlog for planning.

Work comes to my team only through the product owner.

During Sprint Review incomplete product backlog items are carried over to the next Sprint.

My team slices large product backlog items during Sprint Planning.

During Sprint Reviews my team presents our status using a Powerpoint slide deck.

My product owner’s Product Backlog is prioritized by whomever yelled the loudest most recently.

My product owner clearly identifies the value of the work that my team plans to do.

My team takes what the specifications say over what the product owner wants.

Product Backlog Items are clearly identified in terms of business value.

During Sprint Review my team and our stakeholders focus on the outcomes we produced.

My team cannot easily tell the difference between high value and low value work.

My product owner’s Product Backlog is prioritized by business value.

My product owner knows why a product backlog item needs to be done.

My product owner knows the value of their product backlog items.

During Sprint Review my team and our stakeholders focus on the velocity we achieved.

The developers work with the product owner every day to check the work done so far and to answer questions.

During Sprint Planning my team identifies multiple solutions for a backlog item and chooses the best one.

During Sprint Review my team and our stakeholders review progress and make decisions about what to do next.

The product owner modifies the content of my team’s Sprint.

My team uses an artifact management system in which we store code; specifications; etc.

My team checks artifact changes into the artifact management system several times a day.

My team changes what we are doing if a better approach is identified.

My team modifies Sprint content when they believe they can improve outcomes without affecting the Sprint Goal.

The product owner supports the developers during iteration planning by answering questions about the work item.

The developers decides which work items fit into the iteration.

The entire team determines which work items need to be done next.