The next event in our Become Agile Leader serie is certification of product owners that will be provided by Robin Dymond.

The course will be held in Bratislava (Slovakia) on May 7-8th.

Registration is here.

About course

In this two-day class we cover your role in creating a successful product using Scrum. The Product Owner creates the product vision, sets the product goal and leads the effort to transform the vision into a successful product. The Product Owner steers and guides the Scrum team, bridges the gap between customers, business and development, and is responsible for reaching the product goal and return on investment (ROI).

Through simulations and exercises, you will learn how you can leverage Scrum to optimize value creation and customer satisfaction. You will learn how to create a product vision, create and manage the product backlog, prioritize the product backlog, create a realistic release plan, and progressively refine requirements. As a Product Owner your responsibility is to ensure value is delivered early and often. How do you make this happen? This course will also teach you the mindset to support, advocate and implement incremental delivery into production. Scrum transforms the way work gets done, and the Product Owner plays a key role in transforming the business to support regular delivery of value to your customers.

The agenda

The Course Agenda is determined in part by the class.

Topics may include:

• Agile Principles
• What is Scrum?
• Product Owner Role and Responsibilities
• Business Case to Product Backlog

o   A Product Owner Simulation

• User Stories and Acceptance Criteria
• User Story Mapping
• Paper Prototyping
• Prioritization Techniques

o   Hedgehog concept

o   Purpose alignment model

o   Real options

o   The Letters: An exercise in using objective data

• Estimating and planning

o   Release planning

• Organization & Delivery Models

o   Scaling for large product organizations

o   Off shore and distributed development

• Getting to Done

Spoločnosť ScrumDesk ponúka konzultačné služby počas posledných troch rokov. Naša viditeľnosť na Slovensku a v Českej Republike nebola výrazná, keďže sme sa viac zameriavali na spoločnosti sídliace v  zahraničí.

Tento rok je našim cieľom výraznejšie pomáhať spoločnostiam, ktoré vytvárajú hodnoty v strednej a východnej Európe a predovšetkým v Slovenskej a Českej republike.  Krajiny, v ktorých Vám vieme pomôcť sú zobrazené zelenou farbou na mapke Európy.

Viac o konzultačnom centre spoločnosti ScrumDesk, o kurzoch, seminároch, webinároch a certifikáciách nájdete na www.scrum.sk.

————————

ScrumDesk company offers consultancy services for the last three years. Our local visibility in Slovakia and Czech Republic has not been so high as we focused on helping companies especially from West Europe and US.

This year we decided to help companies creating a value in Central Europe, especially  Slovakia and Czech Republic. Except of this region we are ready to support your teams in countries highlighted on map below by green color.

Specialty of our company is an experience with different sizes of companies, from startups to enterprise companies. If  you have an offshore  center in CEE region and you look to improve agile implementation , we are ready to help your teams by providing professional coaching and consultancy services.

As part of this effort we prepared pages in Slovak language listing all courses, webinars and certification classes we will provide either by us or via our partners.

National consultancy centre is available at www.scrum.sk.

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

While being in agile transition, teams look for information how to do agile correctly. Often the question sounds ’How to DO agile?‘ The guideline we prepared might be helpful to shorten your transfromation period and stabilize agile environment earlier.

Download full paper as PDF from http://www.scrumdesk.com/Download/Documents/AgileResources/ScrumGuidelines.pdf

Do you need to learn more about agile and scrum fundamentals? We suggest to start with following  books.

For begginers

Free download, Slovak translation

If you are agile already

Presentations about Scrum

When defining a story, one can fill out an ‘effort’ and a ‘duration’. What is the difference between them?

Effort = size = Story points

Let starts with the story point.  Scrum is „little bit“ different  than other classic project management techniques.

When you want to develop some feature, you have to know the „size“ at first.  Imagine you want to go to a trip. You know your trip will be 1000 miles long. This is the size. Another variable is the time. You want to pass this 1000 miles in 5 days. This is a duration. It is possible to calculate planned velocity as 1000 miles per 5 day. Velocity therefore defines  how much of progress are you able to do.

When we are talking about story points, we are talking about the size.

This size  is evaluated in different units. Standard methodologies use „mendays, cost, etc.“.  Scrum prefers number without the unit. Starting with Scrum this is strange to people. What value I have to put in column „size“? Your first evaluation will be very hard and full of questions.

The best approach to start with relative estimation is to try some example on real life objects. Try to compare phone to laptop and LCD. Use following scenario.

1. Put all the stories (objects) in front of developers.
2. Let them to choose one story (object) that will get the number Effort=1. Typically it is small story like „I as a user want to save file to disk“.
3. Then compare all remaining stories relatively to referenced story and other, already estimated stories.

For example, Story 2 – „I as a user want to calculate average values per years for every customer“ is harder story than Story 1 mention above. I as a developer think that this story is 3 times harder than Story 1. Thus I will put Effort = 3 story points.

You will do this for every story that is in your product backlog. This estimation is done by developers and testers. Team sits together in a meeting room with the product owner and talking about stories, what he wants and needs. Product owner will say us as much as he can. We will ask him from a technology point of view. Some stories are changed during the discussion, some new stories can appear as well.

Product is typically estimated in 2-3 full days during the planning meeting. Maybe it seems too long to sit for  3 days, but this it is very effective time. Benefits: all your developers and testers known what product owner wants. Product owners meets with development team. He see developers hence closer relations can be build.

Size of stories is estimated in the Fibonacci scale. Why Fibonacci? Because it is hard to estimate if story is 20 times bigger or 23 times. Scale is 0,0.5, 1,2,3, 5, 8, 13, 20,40,100. If story is bigger than agreed limit (8, 13 or more) then it should be split into more smaller stories. Why? It is too complex to be developed. If story is smaller, developers can be more precise in theirs estimation. Product owner can be more precise in story definition.

Planning Poker®

During the planning meetings we “play” Planning Poker®. Every developer will get deck of planning poker cards with Fibonacci numbers.

Scrum Master will choose the first story. Every developers and testers will estimates they size of the story:

• John‘s estimation = 1
• Bill‘s estimation = 2
• Andrea‘s estimation = 13

During the game team members hide theirs card. When the round ends up, the team shows cards.

Now they might see that John and Bill are close with values, but Andrea says that given story will be 13 times bigger. Andrea should explains why she thinks is bigger.

They will discuss the reason for estimated number and later a new poker round will begins. These steps should be repeated until team agree on just one number because we look for team’s commitment . This is the number entered in the ScrumDesk story card then.

There is another estimation technique based on „ideal day“. When you are using this evaluation unit, your developers must think about the day when they are not disturbed by emails, meetings, they can work for 100%. Your team must agree what ideal day means in „real time“. For example, my ideal day is 6 hours, although my work day is 8 hours. I spend 2 hours is for meetings, phone calls, emails.

We were using ideal days beginning the agile transition, but later we have found it as a complex way for estimation. Every developer has different „ideal day“. Size in story point is better for estimation as it is smaller and enough for accurate estimation.

Mike Cohn about Agile Estimation

Resources

• Read „Mike Cohn: Agile Estimating and planning“. This is one of the best book about the project estimation.
• Another one is Henrik Kniberg: Scrum and XP from the Trenches. This book is perfect for Scrum begginers and it can be freely downloaded from a page. Must read book.

Doing agile are many obstacles identified. It is not easy to check what does well implemented agile means. A scale of changes that agile transition has brought is often big and related to more areas – to product,  project, leadership, team, tools, development practices and organization as well.

The question asked by teams is “How to identify problems more precisely”? Is there some way we can ensure we are doing what needs to be done in correct way? Is our adoption correct?

Scrum Checklist

An easy way is to use different scrum checklist which are available on Internet. The one, we are using, is Scrum Checklist written by Henrik Kniberg.

It is a set of 70 questions that are easy to be filled up in 15 minutes. We ask team members to fill it after three or four sprints. Checklist are filled anonymously and after we collect them, we do identification of biggest obstacles.

What needs to done to fix the problems is separated session with the team in which we make these problems visible and painful, but with agreement and commitment of the team how to fix it and when.

Comparative Agility

A new interactive solution has appeared in the last few months.  Comparative Agility (collaboration of Mike Cohn & Kenny Rubin) provides a solution teams can use to identify problems more precisely and to compare the results to other companies. It is this comparison that is valuable to understand where your adoption process.

The solution is easy to be used even your teams are distributed. Another advantage is immediate access to results without additional post-processing of received feedback.

Questions are categorized to different areas asking about teamwork, management, communication, requirements process, planning, design etc.  The answer team provides have a scale. that allows the comparison.

The result are displayed in nice charts with standard deviations in which teams can identify areas with the biggest gaps that need to be addressed.

What does it mean for ScrumDesk users?

ScrumDesk company is the assessment partner now. The partnership allows us to help you to provide an account for your company to validate your adaption regardless the size of the company and the number of  locations.

We are ready to help you:

• to determine which parts of the organization need to be assessed
• to provide an unique access to Comparative Agility solution for your teams
• to interpret results
• to suggest you the next steps to improve your agile adoption

Feel free to contact us if you are interested in. We will be glad to help.

One customer asked us an interesting question regarding relations of stories in ScrumDesk.

What ScrumDesk supports now is simple relations tracking solution. Very simple and basic functionality – possibility to track, see and print out it in documents.

For the first look some basic functionality in ScrumDesk is missing. Functionality similar to Gannt chart way of relations (Finish-Start,Finish-Finish, etc.).

Gannt chart relations (Source: Wikipedia)

As you probably know, a good story in agile is written to fulfill INVEST principle:

1. Independent
2. Negotiable
3. Valuable
4. Estimable
5. Sizable
6. Testable

The first is (and not by coincidence) Independent. The reason is simple. To track dependencies in your hundreds stories backlog  is a mess. A big mess. A task that is highly potential waste.

In our experience 80-90% of stories could be rewritten into independent stories. How to do that? I do not have an answer for you. It is not easy, it requires an experience, feeling and still see a value in a slice. But it can be done.

How to solve dependencies?

But how to manage dependencies? IT IS ABOUT PRIORITY! Priority is a driver how to order things in agile, not dependencies. Order stories into releases and sprints. This helps you to forget about dependencies. It is more important.

Set an importance of basic functionality higher than advanced functionality. This way you can add another brick to your wall and make it higher. Brick by brick.

Build a product brick by brick (Source: David Korona, http://www.davidkorona.com)

P.S.

Of course, enterprise backlogs probably require to manage dependencies as well, but it is typically program/product level in which you need to track dependencies of stories on which more teams are working. But this requires probably different beast to manage it.

What about great product owners?

Do you want to produce more quickly with better quality than your competitors? Do frequent changes make your life complicated?

Register Now

Scrum, agile project management framework, changes the way how to develop and deliver products. It has strong accent to adaptability towards requirement changes, shortening the development cycle, team work and quality.

Workshop Scrum in real life explains fundamentals of the framework including roles and responsibilities as well as agile practices and metrics. You’ll learn how to handle large amount of requirements and how to estimate agile way.

We will explain you Scrum through practical examples and game which you can utilize with your teams late when you get back home. This approach is proved to be successful by hundreds of attendees in last couple of years.

When?

April 7th, 2011, 9:00 AM

Price?

80 Euro

Venue?

Hotel maxinn, Pri Suchom mlyne 7, Bratislava, GPS  (48.17209598128045, 17.08077907562256)

Why?

• Learn Scrum, roles and ceremonies. You’ll get information about agile principles and other methods.
• Use Scrum in practice during the workshop.
• Learn how to estimate and react to frequent changes.
• Learn how to prioritize requirements according their business value.
• Learn how to change your mindset to improve development process.
• Learn practical games and examples which come handy for your teams while adopting to agile.

Who?

* Senior management
If you think about transformation of your company to be more effective

* Product management
If you need to work with a big number of requirements and you want to deliver on-time and on-budget.

* Project management
If you want to solve the dilemma of the triangle Budget – Scope -Time.

Workshop Scrum in real life

Agile retrospective is one of the most important ceremony in Scrum. There are lot of sources how to do it. We would like to provide to ScrumMasters and teams an overview how to do retrospective.

And we are starting with Set stage

Reaching wider community is for us absolutely welcome not just because of numbers (either count or price). For us the value is a knowledge  how scrum adaptation is done.

It is very interesting to see how such simple project management framework is adapted  in so many ways.

ScrumDesk development begun as materialized idea based on Scrum and XP from trenches book written by Henrik Kniberg.

The first year of ScrumDesk development we were (maybe) naive. We have decided to implement  ”pure scrum” approach. Of course a reality, trainings, discussions and requests were the source of knowledge to improve tool. Improve it just slightly?

Story

I am sorry to repeat the concept of the story. Maybe it is more for beginners, but there are still a lot of them. And they are always welcome to learn how to improve.

Story in Scrum is short description of what is necessary to develop for who with why on mind. To provide the first template for it (definition by Mike Cohn):

As a [user role], I want [to have something] so that [the benefit].

Typical problem of new teams is how to write stories especially once the team will recognize feature, technical or spike stories. And teams solve this problem by special attribute (or tag).  It is not just this attribute that is necessary to repeat.

Additional could be:

• story type – functional, requirement, technical or spike?
• default estimation – yes, some teams prefer to start with all stories of the same size hence provide “mean” value for estimation range
• default duration – as an indication of how story should be long
• color – do you use colors to indicate story type or importance or assigned team?
• theme

ScrumDesk simplifies story writing providing possibility to customize story templates.

Story templates

Scrum Master is able to prepare stories templates that can be reused by the team to create a new story.

Templates are the way how to keep a backlog managed.

ScrumDesk provides possibility to define different templates according project.

Templates definition

To define templates Scrum Master should login to project. Tempaltes are defined on Project/Customization page.

New template can be added by click on New link.

ScrumDesk story template allows to define:

• template name
• template description
• definition time
• story default description
• story type (user story, technical, epic, etc.)
• Effort (Fibonacci or manually entered value)
• default duration
• tasks

We decided to allow to define tasks as many teams defines the list of default tasks that every story must contains. This list is typically part of definition of done.

How to create new story based on template

Team member can easy select the template from New menu item. Point a mouse pointer to small arrow and templates list will displays.

Now user should just click the template and new story will be created in the center of the board.

Summary

Story templates are helpful not just make stories definition more efficient, but they allows  to keep backlog structured the same way even the team is large and distributed.

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.

Scrum is lightweight process framework. As it is just a framework, you can find the same implementation in world rarely. Even in company level scrum implementation will be different project by project.

To validate our coaching effort we use Scrum Checklist (originally written by Henrik Kniberg). Henrik’s checklist is paper-based survey easy to use during meetings. Coaches however need to validate more teams then just one with a lot of people. Agile in enterprise level is more complicated. You need to apply concept of scrum of scrum etc.

We use Microsoft Excel file to validate teams. This survey is sent to all team members. They are encouraged to fill it separately. After that coaches process files and prepare an overview with Pivot charts. Additionally, coach follows up with face to face meeting with all team members. This way the changes are gathered and coaches can focus on further improvements.

You can download checklist from SlideShare.

Successful companies are looking for the ways how to improve processes all the time. Sources of improvement, in companies driven by traditional management, are mostly selected people from senior management and/or process engineers.

The problem is, as we in agile community see, that source of improvements are not the people directly doing the job in many caes. Of course, these people are questioned  (at least) by different surveys with pre-formulated questions that lead to strange situations. We’ve seen couple of  surveys with questions like: “Do you think our company XXX is moral?”. Or “Do you think our company supports Safe Earth effort?”.

Do these questions sound little strange to you too ? Especially if the title of survey is  How to improve our company (Global Survey)?

In scrum (retrospective) such questions should be open questions. Questions looking for ideas, not expecting YES/NO answers.

Coaches used to coach people to ask them during scrum ceremony called retrospective. There are different ways how to lead the retrospective. The simplest way  is to ask What is good?, What can be better? and Any other ideas? Teams can apply voting, grouping, sorting etc.

We tried different approaches during last few coaching sessions. These sessions were primarily focused on improvements of project and product management teams, that were not working  agile way and were little bit reluctant to hear about agile or scrum. We used Speed  Boat innovation game.

The principle of the game is to draw a boat with couple of anchors and engines. The boat should be named to represent a focus area (especially if you  are going to examine large group of problems).

Ask team members to write what is slowing down the boat (one idea per card) and to pin the card to anchor. Let team members to write ideas what can speed up the boat and pin cards to an engine. After that you can apply grouping, sorting and/or voting the same way as you know in retrospective in agile/scrum.

We created couple of boats during our session. People presented a lot of ideas without any hassles and what more, they freely promoted possible/expected  solutions that were immediately changed into action items for directors.

Speed Boat game allows not just open minds, but efficiently provides a strategy how to solve your problems. Additionally, trust and expectations are more clear.

Missing the happy end? Open ending is what the real life is about.

Let’s meet in the next Speed Boat session after couple of months to check how process is improved and to provide new ideas.

A review (or demonstration) is fundamental scrum ceremony providing a visibility of results to a product owner, stakeholders or anyone invited.  For agile team, the review is a key event as commitment they agreed on must be demonstrated as a real functionality.

We spent couple of few days on-site with teams we coach. Focus of our sessions was a review of stories developed during the last sprint. The review was apparently different than it used to be ” before the scrum”. Teams demonstrated real features , not just slideshow presentation.

It is challenging, in an enterprise environment, to demonstrate product to be really done. And if you are in Business to Business to Customers (B2B2C), it is even harder.

It is not always possible to deploy completed features to production environment as this change can be a change of contracts signed between companies. This was a reason to use powerpoint presentation before going to agile. Presentation contained not only description of the features, but a lot of  data in details  ( tests completed, test data etc).

We had to establish “an inter-company contract” first. An agreement of target environment used for demonstration. Team was lucky to agree on that so we had a chance to do real demonstration.

Review went well and all stories were accepted without any surprises.

Surprises came later.

Our coaches were asked by senior manager why slide-show was not a part of the review anymore. They were surprised as they were used to see only presentations and then present it to customers.

The question was: “How we should get an approvement from customer now? We have nothing to take away and demonstrate  the result.”  This question confirmed that mindshift to agile thinking is a long-term process.

Developers  develop products, not write powerpoints.
Products fulfill expectations of customers. Powerpoint doesn’t.

(Published with Mike Cohn permission)

Part 1:

Part 2: