You know that probably.

Requirements are coming, coming and coming.  There is no time to stop and think about them. There is no time to organize them. There is no time to analyze your backlog so you know which requirements should be developed as next. Even more, many customers ask you of new functionality or defect fixes.

In our last training we tried Innovation Game approach to gather product requirements and break them down into manageable size.

The game is called Prune the product tree.

See more on InnovationGames page.

Prune the Product Tree game

The principle of the game is simple. Draw a tree on flipchart board that will represent your product. Then, ask either your customers, your product owner or the team to start to draw limbs.

Thick limbs will represent major areas of functionality.  These limbs will represent epics in your backlog.

Then draw thin limbs on thick limbs. These thin limbs will guide your teams to be more specific about the major functionality. Visibility of the tree and limbs will guides them to be structured. In agile terminology these thin limbs may represent themes.

And, do not forget leaves. Leaves are small and without them the tree will not survive. You need leaves, but maybe not all of them. Leaves represent stories.

Try to even use the distance as visualization of necessity. Edge of the tree (outermost branches) are probably not so necessary, they will be developed in some next version.

Do not forget to check  ’the weight’ of limbs. Are some limbs thin with few leaves only? Maybe they are not so necessary.

Is your tree well balanced? Maybe some features are less important, or they simply miss fundamental functionality.

What you see observing your tree?

The Game

Credits

• Tree picture rights reserved by jrsnchzhrs

Our previous blog posts were about core product ownership approaches how to prioritize backlog according to business value.

Another dimension a product owner should know is expected customer satisfaction. Satisfaction with developed feature or story.

Mr. Noriaki Kano developed Kano model as valuable technique helping to recognize that. Applying this method the product owner can identify importance of stories by asking questions like these:

Is the feature mandatory? We will not earn additional revenue once we have it but without it the product doesn’t fulfill existence principles.

Having a feature, will customer say: “Hey, that’s nice! I like this approach and it seems to be really helpful.” This feature is excitement. It is possible differentiator.

Well, guys  improved a performance of the application. This is valuable.  Comparing to other products, this product is one I would like to use.

Hmm, this feature is indifferent. It doesn’t matter if this feature is or is not implemented. If vendor provides it, ok, I accept it. If it’s not implemented, no problem then.

This feature is really questionable. I am not sure if I am going to pay for product with such feature. It will probably slower me. Also, I assume it will complicates usability in my company. Let’s think about different  product.

Ohhh no! Not the feature like that. You are kidding. This feature reverse me to really find a different product.

Such perspective is great way to identify priorities in complex backlog.

Illustration of features vs satisfaction (Wikipedia)

How ScrumDesk integrates Kano model

A story in ScrumDesk provides possibility to gather data about expected customer satisfaction level in story detail window, Priority tab.

The level of satisfaction is possible to change in stories grid where data can be analyzed using filters and grouping features that grid allows. Grid allows an inline editing so data can be changed easy.

If the backlog is complex, then tree map can helps to product owner to validate priorities vs customer satisfaction.

Stories grouped by satisfaction level, color by the current status
Explanation: One excitement story is developed (green) even there are more mandatory stories. Product owner should validate priorities & contact team.

Another overview of the backlog is available in Satisfaction and effort chart. This chart is accessible in Reports/Prioritization tab. The chart displays distribution of effort according to assumed customer satisfaction level. It is easy to recognize if developers are focused on correct stories.

Product owner  is often confronted with a large backlog. This post continues  to explain how to consider priority of stories. See principles in previous post.

Measuring risk and positive value allows to calculate the order in which stories should be developed. Very nice and simple visualization can be Risk  vs. Value chart.

Chart is split into four segments. Small dots represent stories. They are colored according to the status of the story.

As Product Owner you would like to deliver the most valuable stories as the first. But development team can find them too risky.  Good risk management suggests to focus on the riskiest items as the first.

Combining these two attributes ScrumDesk suggests to develop the most valuable, but the riskiest stories as the first.

Second stories to be develop are still stories with the high value, but they are less risky.  Development team is able to finish them in more manageable way.

Which stories should be never done? The riskiest with the lowest value. Why to develop something that  earns $0 while it is very risky?

What to do in this case? Explain customers about your point of view and delete them from a backlog. If you can…

Using this approach your development team can be sure it develops what is needed. One look on such diagram helps to  Scrum Master and Product Owner to validate the order and focus the team.

Agile coaches teach  teams to develop a  business value that is delivered at the end of the sprint.

But should be a value an indicator of the priority? Yes, but not the only one. There are many other attributes we often forget to consider.

We suggest to apply different approach. We would like to have a possibility to calculate priority according business value but considering  risk and effort as well. This way we can have the priority more precise, not just guess.

Product owners often see only  positive business value. It is a value a company will gain if story is delivered. But there is negative value that drags your revenue down. Example of such negative value is non logical login during pages transitions.

Risk should be not forgotten.  You can see risk management done in different ways. From High->Low or as numbered risk level. The more risky story, the higher priority.

Dependencies is number of relationships to other stories. The more dependencies the higher priority as problem seems to be more complex.

Effort makes priority non-linear. What is smaller it can be done sooner as it is much more precisely estimable. Big stories are typically epics that must be detailed hence they are not good for the implementation.

ScrumDesk uses this approach after consultations with our top    customers. We learnt to apply this way in our backlog. It provides us  validation of our priority feeling comparing to calculation.

It is very easy to accept proposed priority by clicking  Set to  importance.

In this step product owner and development team will try to plan project sprints.

Who

Product Owner

Scrum Master

Planning in SCRUM

In Step 4 Planning product releases we defined sprint as time box for developers to complete selected stories.

Product Development
Product Backlog
Release A		Release B
Sprint 1	Sprint 2	Sprint 3

ScrumDesk: Planning sprints

In part 4, product owner defined that RSS Reader must be released in two releases. These are deadlines for development team.

In the Step 4 we defined 3 releases and 1 sprint was created by default.

Time to release can be divided into smaller time boxes, sprints. Our development team agreed with product owner on 10 working days sprint length. This will be constant duration of sprints during development of the RSS Reader.

Sprints can be planned in Planning view. This view can be displayed by click on Planning menu item.

Top half of the screen is a virtual board for all stories that are in backlog and that are unassigned to any team member. These are stories that have to be developed.

Bottom half of the screen is another virtual board displaying stories assigned to Sprint 1 and all releases. Sprint 1 is selected in a left bottom combo box.

Below the combo box is displayed pane with commands that enables to users to create new sprints, remove current sprint and to display sprint details in Sprint detail dialog where they can be edited by Scrum Master.

These details are displayed also in a pane. In advance, sprint details  displays occupation calculated in real time. This is an indicator how much story points can be developed in current sprint. Maximum value is equal to a Sprint capacity value.

Create Sprint 2

Click on bottom New command under Sprint 1 combo box. Sprint details dialog will appear. Enter the values according to a screenshot below and close this dialog.

ScrumDesk supports extra date for demo. This way the sprint demo can be planned later than sprint end. This can occur when product owner, stakeholders or management are unable to plan theirs time to sprint end.

Sprint length is given as a number of working days. ScrumDesk automatically skips weekend days when calculating burn down charts. Thus only working days are required to count.

State of the new sprint is set to Planning. Sprint in this state is in plan phase where stories can be assigned to the sprint. No story can be started. This prevent team members to start stories sooner then team agreed.

Only Scrum master can start sprint. This can be done in combo box State in Sprint detail dialog or using a big red button in a SideView. After the sprint starts, ScrumDesk begin to calculate sprint progress. This will be displayed in burn down charts, time sheet and other reports supported by ScrumDesk.

Sprint can be finished by scrum master only when all stories are completed. In case that some of stories was not completed, scrum master or development team can split stories or tasks to a next sprint and complete stories.

Sprint 3

Now create last Sprint 3.

Result

Your timeline now displays plan for your product: 2 releases and 3 sprints.

In this step product owner and development team are going to plan project sprints.

Who

Product Owner

Creating stories

Target for this step is to create backlog stories.

Product Development

Product Backlog

Stories in scrum are mainly created by product owner. As a first step let’s log in as product owner.

Product owner is responsible for requirements specification and prioritization.

Choose your project and switch to Product Backlog. Product backlog is a container where anyone can see all stories displayed as story cards.

ScrumDesk is primary a virtual board. User experience very near to a wall with story cards.

Creating new stories

Stories can be created on board in different ways:

• by click on New menu item
• by Insert key on your keyboard
• by double-click on board
• using a template from Templates pane displayed by click on arrow below the New menu item

Story

Story in scrum and ScrumDesk is described by a story card containing following attributes:

• Id, (number 5605),  that uniquely identifies story
• Subject, short name of story
• Description, more requirements details
• Priority, (number 50), the level of product owner requirement demand
• Effort value, relative size of story in story points. Estimated value can be selected only from predefined list of values obviously used in scrum method.
• Duration is number of days necessaries to finish the story.
• Operator, team member responsible for story implementation
• State of story is indicated using color bar in left top corner. Clicking the bar you will change the story state. For more details about state look at Story states.
• Theme, name of the theme which group stories

Step – creating stories

Let’s create new story  Adding a channel.

1. Double click board
2. New card is created
3. Enter the subject: Adding a channel
4. Enter the description:As a user I want to add new channel
   - by entering channel URL
   - using a drag and drop from web browser
5. Enter the importance: 90 This will be highest priority story. Priority number and range is depending on Product owner decision. Development team must understand this values range.
   ScrumDesk uses number priority as it gives Product Owner better granularity.
6. As a theme enter User Interface or UI.
7. As you are logged as a product owner, you are not able to change Effort nor Duration properties.

Your card should look like this:

Now you can enter other remaining stories. You will enter stories  in a Grid view. Click Grid menu item .

Story Categorization

Don’t forget to set Theme and/or color of the card. This way you can categorize stories into more categories.

Tags

You can use story tags available in a story detail window. Stories can be filtered by tags from the SideView.

In this step product owner and development team will plan sprint.

Who

Product Owner

Scrum Master

Developers

Visitors

Sprint planning meeting

Development team meats with product owner on sprint planning meeting. Product owner shows the team his plan for first sprint. Product owner chose stories by top importance (priority).

Product Development

Product Backlog

Release A

Sprint 1

Planning

………

Planning View

Switch to the Planning View by click on corresponding menu item. This view provides access to all product planning activities. Users can based on theirs role in a project to:

• manage releases
• manage sprints
• assign stories to sprint and to release
• change details of stories in Detail window

View displays two boards. Board display stories of sprint and release selected from corresponding combo boxes which are near to board.

We prepared Release A and Sprint 1 in previous steps. We have backlog stories written in our backlog. Now we will plan our first Sprint.

Prepare the view

Let’s display stories unassigned to any sprint:

• Choose <Backlog unassigned> from combo box in the upper board.
• Choose Sprint 1 from combo box in the bottom board
• Choose Release A from combo box in the bottom board on the right side

Assign stories into sprint

Sort backlog stories by Importance. Now you can drag stories from upper board to bottom showing the Sprint 1.

Drag stories until the sprint’s occupation indicator will not indicate sprint fullness. This indicator calculates sprint occupation by sum of stories’ sizes. This sum must be less or equals then Sprint capacity value entered in the Sprint detail window.

Occupation indicator

Sprint detail window

As you can see capacity of Sprint 1 is set to 5 story points. This is a value upon team agreed. It is maybe to low, but team is just starting first sprint and team members don’t know how fast are they able to work.

We can assign only one story to this sprint. It is a story “Protocol selection (priority 60, size 5)”. Drag this story from upper board and drop it to bottom board.

You have completed planning for your first sprint now.

It is good to do sprint planning before each sprint. This is a way how to develop your product in an iterative manner.

Task planning

Every team member must specify tasks on which he will be working. He must estimate duration of every task. Total time of the work will be checked to this duration.

Task can be planned in ScrumDesk different ways.

1. Most valuable is Task board. Task board displays stories and theirs tasks in a Kanban view.
2. Tasks can be specified in story card on a page Tasks. Tasks can be added, removed, edited and it is possible to change order of the task in story.
3. Next view where tasks can be managed is Story Detail with Task page.