Scrum relies on the truthfulness of Team Members to allow for transparency about the internal quality of the product. Internal quality is primarily related to the technical aspects of the product: its design, its architecture, lack of duplication in the code, and the level of coverage of the product with automated tests. Scrum relies on the professionalism of the Team Members for the proper implementation of this rule. Being upfront, transparent, and truthful about the internal quality of the product allows for the Product Owner to understand how much time and effort the Team will allocate to improving the internal quality of the product and how much will be allocated for new features. This also gives the ScrumMaster an opportunity to connect with stakeholders who may be able to help remove technical debt and waste that is continuing to exist. If Team Members are not truthful about the internal quality of the product, over time the system will become more cumbersome, more complex, and more painful to improve. This will also lead to a culture of hiding problems, which diametrically opposite to the intended use of Scrum: to uncover problems and allow us to solve them. Another downside is that morale will begin to decrease as Team Members care less about the quality of their work. This, of course, will ultimately lead to external quality problems that result in customers being unhappy and looking for someone else to work with.
Each member of an organization has a title or designation that may reflect their responsibilities or profession. These titles may include BA, Tester, Developer, QA, PM, and others. It is normal to be proud of our accomplishments, achievements and titles. Unfortunately in a Scrum team these titles can limit the individual and adversely effect the team. These same titles can label the individual as that role (example – as a tester) and only that role. Within a Scrum team we certainly need the skills, knowledge and abilities that come with that title/role, but we do not want to limit that person to being viewed as only that role. Each of us is the sum total of our experience, education, values, upbringing and history. All of this is of value to the team. We should encourage every member to fully participate on the team, to willingly share their expertise, to contribute to non-traditional tasks and to feel they are valued as a complete person rather than a specifically titled individual. So if the goal is to leave your title behind, then it is implied you can also pick up other skills.
So how can this be accomplished. One way is a Skills Matrix. This is a chart that can be posted in the room to identify the skills needed and the people on the team. On the left column you list all the team members. Along the top you list all the various skills you need on the team. Then each person reviews their row, looking at each skill, and then identifies how many quadrants of each circle they can fill in, based on the range below the chart. The range is from no skills through to teach all skills in a given column. After filling the columns and rows, now the work begins. By using pair programming (an extreme programming method) and other methods like self-study and taking additional courses, the team member can begin to learn other skills. The objective is to have at least two persons on each team who possess each of the skills at the level of performing all the tasks of a specific skill. The goal is not to have every one do everything but to have a least enough people with specific skills to cover sicknesses and vacations so that required tasks are performed. This is a method to capture the full extend of each person’s current knowledge, skills and abilities and expand on it.
Since they are hard to see, here are the labels for the number of quadrants:
0: no skill
1: basic knowledge
2: perform basic tasks
3: perform all tasks (expert)
4: teach all tasks
The User Story is a tool developed with Extreme Programming that is almost universally accepted as part of Scrum. The User Story format is an effective way of communicating end user value to the Scrum Team. The first blank is a user (a person, not a system), the second blank is the action of the story (unique), and the third blank is the benefit (for any stakeholder, and outside the system). A User Story is made up of three “C’s”: Card, Conversation and Confirmation. The Card is the written version of the story (usually a physical card on the wall). It is considered to be an “invitation to a conversation”. The Conversation is where the real value resides and potentially involves all stakeholders. The Conversation can cause changes to the Card. Confirmation is the acceptance criteria that, when tested against, confirms the valuable result of the story. A User Story is an extremely effective way of creating light and conversational PBIs – this is why many Scrum teams use them. Another way to view User Stories is that it tells any reader the “who”, the “what”, and the “why” – who cares about this, what is the need/action, and why does the person want this. This is just enough information to make sure that an effective conversation occurs.
Product Backlog Items are ordered into a sequence in the Product Backlog in such a way that the Product Owner is able to maximize the return on investment (ROI) in the team. The very first PBI in the Product Backlog should be the one with the highest expected value considering the effort to build the PBI. There are many ways to calculate this expected value including Return on Investment (ROI), Net Income After Taxes (NIAT), Net Present Value (NPV), etc. The Scrum Team members should be free to ask why one PBI is prioritized higher than another, and the Product Owner should be able to give a reasonable answer. Since the entire Scrum Team is accountable for its work, it is in the best interest of all members of the team to use expected value, so that both the Scrum team and the customer will be committed to the work that is currently being worked on and the upcoming work in the future Sprints. If we don’t order the PBIs by expected value, then the Product Owner is likely to prioritize them based on dates, feelings, urgency, or other less valuable methods. These other prioritization methods will diminish the trust of the team in the Product Owner and may lead to morale problems.