Product Backlog Refinement and Prioritization with the Help of the Kano Model

Tremendous fluctuations in requirements, the heat of the market, competitiveness -- these are a few factors that arise during product development and force stakeholders to keep a continuous watch on the market and ask for quick changes as and when required. The Kano model helps Scrum product owners during product backlog refinement, in light of such changes and demands.

In Scrum, we welcome feedback and change requests from stakeholders, but it is important for a product owner to categorize and prioritize both change requests and the demand for inclusion of new features. At times the requests are just fancy tasks and do not contribute much value to business; hence they may be taken up later or could be discarded. On the other hand, some complex tasks provide good value to business and hence need to be taken up immediately. To get a grip on the flow of such requirements, the product owner needs to identify customer needs, analyze competitive products, analyze the value of such features, and -- based on all of that -- prioritize the product backlog items.

The Kano Model of Customer Satisfaction divides product attributes into three categories:

1. Threshold attributes
2. Performance attributes
3. Excitement attributes

If any product might be competitive in the market, then it must meet all threshold attributes (must-have features), performance attributes (should-have features), and excitement attributes (good-to-have features with value for business).

Let us take an example of a mobile phone.

Threshold attributes would be the ability to make outgoing calls and receive incoming calls, inclusion of a built-in camera, etc.

Performance attributes would be long battery life, a strong body, etc.

Excitement attributes would be assistive light, navigator apps, etc. These excitement attributes increase customer satisfaction, but their absence does not lead to dissatisfaction.

A challenge for a product owner is to manage the flow of multiple requirements coming from stakeholders and bring everyone to consensus about the requirements that provide the greatest value to business.

There are many approaches to limit the flow of requirements. A simple approach that's helpful for prioritizing the product backlog items is to ask stakeholders two simple questions for each attribute:

• Can you rate your satisfaction level, assuming the product has this attribute?
• Can you rate your dissatisfaction level, assuming the product does not have this attribute?

Use a scale of 0 to 10 for both questions. Tally the answers provided by stakeholders for each attribute. The result will help the product owner reach a conclusion. If, for each question, the counts fluctuate a great deal, the product owner can use Planning Poker to get a more exact count for each attribute/requirement and help all stakeholders come to consensus on that.

If you have more suggestions for product owners to help them manage and effectively prioritize the flow of requirements, please share your ideas

Originally published at Scrum Alliance web site- https://www.scrumalliance.org/community/articles/2015/january/product-backlog-refinement-and-prioritization-with

Invent...but do not re-invent the Wheel!

I would like to start with the old saying, "Don't reinvent the wheel." And really, it is an important message! When the wheel was invented, it was made of a simple wooden log. The requirement increased and gradually there were many value additions, such as spokes, rims, tires, alloy wheels, tubeless tires, etc. And that's what we do at our workplace on regular basis: put value additions onto our work.

For example, we use the same libraries already used by thousands of programmers earlier, but we extend these, make some tweaks for specific requirements as and when needed. Hearing this, I know some of us smiled and murmured, "Inheritance?"

Recently I had a talk with a group of IT professionals. I was trying to understand their views on agility and especially on Scrum. (Being a big proponent of Scrum, I love to get involved in such discussions and guide people toward the benefits of Agile and Scrum -- benefits they are not always aware of.) To my surprise, they straightaway remarked that Scrum was not going to help them produce their product. They had already discussed this extensively with other Scrum practitioners.

Later I came to know that their product was reported with many defects, most of them due to not understanding the requirements correctly -- and of course there were a few change requests as well. The product was out, and till the existing defects were resolved there was no plan for next releases. So do you think that coaching them on Scrum was the right step, when there was a sheer need to deal with the current situation? The alternative Agile approach to suggest to them was Kanban. I discussed the way they were handling things and proposed that they follow Kanban principles of visualizing, limiting the work in progress, and managing the flow. They tried Kanban and, as expected, it worked well. Kanban helped them manage the work flow fantastically. And now they were interested in discussing Scrum for their next release. There are still lots of challenges to face, but at least the start has been made, and made well.

This was one such case. The big misconception about Scrum is that it is a tool that can develop products rapidly, inexpensively, and with quality. No! Scrum is not such a tool. Scrum is a framework that helps teams work differently, think differently, and develop products with the goal of the satisfaction of all involved. There are no hard rules in Scrum to follow, and there can't be. Product development is too complex for a single set of rules to fit in all circumstances. Scrum is a proven framework that suits most domains and most situations. To experiment with and enjoy Scrum, you have to identify the requirements of your organization and, if required, tailor the Scrum practices to suit those requirements, while ensuring that the essence of Scrum does not get vaporized. As a next step, your tailored Scrum may lead to Lean Agile practices for your organization. Enjoy it!

Pros and Cons of Modification in Scrum Ceremonies...

Agility is not a new phenomenon. It has evolved with time, the sincere efforts of the Agile community, and its great proponents. Scrum, an Agile framework, achieved popularity with its high number of success results. Development teams started transforming as Scrum teams and a new servant-leader "ScrumMaster" emerged. For the past few years, Scrum has attained wide recognition, and even those organizations that initially overlooked its benefits are now transforming to adopt it. Due to the high success rate of Scrum-led projects and the increased requirements for ScrumMasters and Scrum product owners, many professionals have embraced these roles cheerfully. However, in the enthusiasm a few (wrongly) modified processes are being practiced in many organizations, which sometimes results in failure and stepping into non-Agile methods and myths. I appreciate the efforts people are making to adopt agility while molding some practices to better suit their organizations, but one should take a few preventive measures and inspect such modifications before implementation. This is important not only for new teams but also for matured teams that experiment with such practices and sometimes face adverse results. By saying this, I do not intend to say that we should not experiment! Scrum itself provides room for some calculated modifications. However, before applying such modifications, pros and cons must be considered. I have coached many teams and faced challenges of this type. I have had to implement good practices in some existing teams. The most common behaviors I observed that needed to be changed were as follows: Modifying the names of the ceremonies Not timeboxing ceremonies Treating programmers and testers differently Implementing Scrum without inspecting and understanding the current state of the existing project Modifying the names of ceremonies I found strange names given to a few ceremonies and observed ill effects. For example:

Daily Scrum -- Daily stand-up, daily Scrum meeting, daily status meeting (the worst name)
Sprint review -- Sprint demo meeting

There are two main disadvantages of such renaming. First, not having a common name across the globe leads to misunderstandings. 

"What's in a name? That which we call a rose by any other name would smell as sweet." Great lines by William Shakespeare (Romeo and Juliet)! But in software development, such renaming causes confusion. For example, we cannot call the sprint review a sprint demo or some other name. Even if renaming works within the organization, the rest of the world will be baffled. The second disadvantage is that most names have some significance; using other names ruins that. Calling the Daily Scrum a daily status meeting is certainly going to convert it into a status-reporting meeting. Many teams have experienced that, without their realizing it, the Daily Scrum has become a status meeting and lost its significance. In our teams, we made a rule to follow the proper name of the ceremonies to keep everyone synchronized. The same way the sprint review was named a sprint demo; the sole purpose of this ceremony was to demonstrate completed stories/tasks. The teammate who had coded the particular piece of function was responsible for demonstrating it to stakeholders, and other developers were not highly attentive during that demo. It was important to realize that the demo was not only for stakeholders; it was for the whole team. We guided the team to understand the significance of the sprint review and provide the transparent current status to stakeholders. It took time, but providing various examples rejuvenated the team. There are a few other names that need a common tag. For example, "acceptance criteria" and "condition of satisfaction" are the same. Scrum experts are making efforts at this. For example, "product backlog grooming" is now often called "product backlog refinement." Many more are yet to come. Not timeboxing ceremonies This can be challenging -- and linked to modified names. In working with one team, I found that the Daily Scrum was being called a status meeting, and it was not occurring daily. Due to different time zones among the distributed teams, it was held on alternate days and for longer durations. The team was providing the status of the past two days' activities. All teammates sat and provided their status, one by one. The activity descriptions were monotonous and the energy was very low. Further, I observed that the development team found this meeting time-consuming and of no use. We first timeboxed it and limited the questions/answers. (Two additional questions had crept in: "What did we do the day before yesterday?" and "What will we do the day after tomorrow?") We succeeded in convincing everyone that the Daily Scrum should indeed be held daily and that the three original questions would be discussed. The another problem, of answering these three questions while facing and essentially speaking only to the ScrumMaster in a status report, was solved by guiding the team toward the essence of this meeting and positioning the ScrumMaster behind the team, which stood in a half circle. To revitalize the team's energy and sense of cohesion, we introduced new Scrum games. One such game that I introduced is one that calls on everyone's imagination. Please refer my post 'A game of Imagination'.

Treating programmers and testers differently Treating programmers and testers differently is a very dangerous practice and definitely leads to failure. In such situations, programmers and testers do not focus on the target and instead try to find each others' mistakes. In our development team, we called everyone a developer and focused on achieving the goal on time. This helped us avoid unwanted slippage on tasks. For team bonding, I experimented with many varieties of the above-mentioned game and succeeded in achieving excellent team bonding. Implementing Scrum without inspecting and understanding the current state of the existing project This problem, which I observed strongly in a particular team, is certainly common among many new Scrum proponents. Scrum can be used with all projects but is not highly useful in certain situations. For one of the teams that had recently delivered a product with many critical defects, implementing Scrum was not a good idea. The requirement was to immediately provide needed solutions and keep to the task in hand (limit the Work In Progress). We finally got that situation under control by providing the immediate defect resolutions, and then we started following Kanban for support activities. 

Finally . . .

Now each of our teams follows the Boy Scout rule (always leave the campground cleaner than you found it). Whenever we find a process derailing, we gather and discuss it and get it back in place. If you too have faced any such derailed processes, please share your experience, along with the resolution you and your team took.

Continuous Integration during Agile Development Practices

Continuation integration is necessary in software development, and especially so in Agile frameworks...

"Continuous integration," a term coined by Martin Fowler and Kent Beck, refers to one of the best ways to improve productivity through automating a few tasks during development. Examples include automated pulling of the latest version of code, automated build, and automated execution of unit tests with immediate feedback to the users about the result obtained. Why is continuous integration required? We've often experienced programmers writing code and the task working perfectly, but later, while we integrated that code with the rest of the application, we faced unexpected results. To overcome such situations, continuation integration is very much needed. It becomes more important with Agile frameworks, where the nature of delivery is incremental, iterative, and in short cycles (as in Scrum, XP, or in fact in any other Agile framework). Continuous integration is possible only through an automated process that builds, tests, analyzes, and deploys the application. This process runs with each source-code change and provides immediate feedback to the development team. Minimum human intervention in these processes results in saving time. Continuous integration also reduces the risk of delivery slippage as the development team performs testing and integration on a continuous basis. This helps us identify defects in time and take appropriate and necessary action. The integration may be daily, weekly, nightly, release based, or for testers as per requirement -- and it must be, of course, done in a continuous manner.

How will the process be changed?

Manual process: 

Good flow, with no exception of errors faced during any of the following actions: 

Check out the source files from your source code repository.

Make necessary changes to the code.

Build. Run unit tests.

Check the updated code into the source code repository.

Automated process:

An automated system keeps track of the source control system and, as soon as it finds any change, it takes the latest version of the code.

The system automatically builds the code.

The system automatically runs unit tests.

The system automatically sends build and test results to a feedback system so that team members can know the current status of the build.

Necessary tools

Here I have mentioned a few open-source tools for Java and .net. There are many other such tools that may be adopted by teams as per their preferences. 

Source control: Such as Subversion or Git; these both can be used for Java as well as for .net

Server for continuous integration: CruiseControl.NET (for .net), Jenkins (for Java)

Build Manager: MSBuild and NAnt (for.net), Ant (for Java)

Unit test frameworks: MSTest and NUnit (for.net), JUnit (for Java)

Code-analysis tools: FxCop, StyleCop (for.net), CheckStyle (for Java)

Testing tools: Selenium (for both .net and Java) 

If you have more suggestions, please share.