Overview

Though we introduced two physical boards for managing the product and the sprint backlogs, I’m still searching for a method to organize their items in a manner that fits our needs best. There are two books sitting on my couch which I hope to read during the Xmas break. Both are written by Mike Cohn and seem to be standard works for agile addicts (and even recommended by Ken Schwaber).

User Stories Applied

Here’s just a short citation of its¹ back cover:

Thoroughly reviewed and eagerly anticipated by the agile community, User Stories Applied offers a requirements process that saves time, eliminates rework, and leads directly to better software.

Of course the book is not only about user stories, but also about all of the adjacent topics.

Agile Estimating and Planning

Again a short citation of its² back cover:

Using the techniques in Agile Estimating and Planning, you can stay agile from start to finish, saving time, conserving resources, and accomplishing more.

Again, this book is about management of agile software projects in common and not only about estimating and planning. I hope to learn a lot by reading them.

¹ Mike Cohn, »User Stories Applied« 2004, ISBN 0-321-20568-5

² Mike Cohn, »Agile Estimating and Planning« 2006, ISBN 0-13-147941-5

Before gaining the Professional Scrum Master I certification two days ago, I gained the Certified Scrum Product Owner certificate after a training with Roman Pichler in february. I’m currently listed as CSPO at scrumalliance.org.

Overview

Four weeks ago, I wrote about trainings, classes, and certificates. Meanwhile I attended a PSM training with Ken Schwaber.

Assessment

Part of the contract was one free attempt of scrum.org’s Professional Scrum Master I Assessment, which I successfully passed yesterday. It consists of 80 multiple choice questions, and the timebox is 60 minutes. To gain the certificate, the rate of correctly answered questions must be better than 85%. IMO you won’t pass the test in case you do not really share an agile mindset, which is required to answer some of the questions. In case you got interested, there’s the Scrum Open Assessment which asks 30 questions in 60 minutes (which I finished in 17 minutes).

Certificate

While writing this posting, scrum.org sent me the logo (see above), the certificate, and put my name on the stack. For me, two years after I introduced Scrum at my current employer’s, it’s just one minor step while learning more about product management, project management, agile software development (including Scrum, of course), and adjacent topics.

Inspect and Adapt

So what’s next? The more I learn, the more I want to learn even more. The next stack of books already is sitting on my couch, and I really enjoy the journey to grow my agile capabilities. The future will prove whether I will find opportunities to make good use of them.

During this year’s ScrumDay, sipgate searched for talents by distributing this flyer:

Content Translation

As it is written in german tongue, here’s a brief abstract of its content:

• Five Scrum Teams are responsible for the products.
• Team members are visiting trainings and conventions frequently.
• Attractive office.
• Extra office hours are avoided.
• Thirty days of vacation are granted.
• Employments are long-term contracts.
• No pressure by investors or banks.
• Team building is not limited to office hours. It is continued during parties, BBQs, and even breakfast.
• Bleeding edge products are developed with joy and passion.
• sipgate is a successful and growing company.

High Performance

The goal of agile product development environments is to set up »high performance«² teams. To achieve this in order to develop »products that customers love«³, you need to hire outstanding people, who will joyfully give the very best they can.

The flyer states that sipgate does not only talk about agile product development, but that they are applying it day by day. Its back provides a checklist for meeting invitations:

Freely translated, the statement below the list reads as follows:

At sipgate this list is used for two reasons:

• It requires to plan any meeting so it gets clear whether the meeting is necessary.
• The invitees can verify whether it makes sense to attend the meeting.

Conclusion

The reader gets the impression that sipgate does not only talk about agile, but is actually doing it all day, so that chances are given they will attract the “right” people. IMO it is a great example of recruitment of an agile company.

Thanksgiving

I’d like to thank sipgate for providing the flyer in PDF format and for the permission to use it for this posting.

¹ Boris Gloger, André Häusling »Erfolgreich mit Scrum – Einflussfaktor Personalmanagement« 2011, ISBN 978-3-446-42515-6, chapter 3.1

² Lyssa Adkins, »Coaching Agile Teams« 2010, ISBN-13 978-0-321-63770-3, chapter 2

³ Roman Pichler, »Agile Product Management with Scrum – Creating Products that Customers Love« 2010, ISBN-13 978-0-321-60578-8

The Scrumday conference 2011 (which was sold out) is past. The focus of yesterday was on workshops (I enjoyed »Value driven product development framework with Scrum« by Jürgen Margetich, bor!sgloger Consulting GmbH) and community building. Today started with keynotes of Thomas Kiessling (Deutsche Telekom) and Ken Schwaber (»How to sell Scrum in your organisation«) and continued with traditional talks. The last one was done by Boris Gloger and André Häusling built ’round their new book »Erfolgreich mit Scrum – Einflussfaktor Personalmanagement«, a topic rarely covered yet (I hope the book will appear in english language also). A further talk I enjoyed was »Agile Developer Skills« by Christoph Mathis, also built around a book².

As always, it was a great chance to learn things from practitioners which you cannot learn from books. This was a worthwhile event for the Scrum addict I am :) .

¹ Boris Gloger, André Häusling »Erfolgreich mit Scrum – Einflussfaktor Personalmanagement« 2011, ISBN 978-3-446-42515-6, pages 81 through 85

2 Christoph Mathis, Andreas Wintersteiger »Agile Developer Skills«

Janus, Vatican, via Wikipedia, public domain

Ken Schwaber continued his excellent training on Friday.

Training Style

The key ingredients of his style are:

• Story Telling – an important technique, and I recommend this posting of Garr Reynolds (found via Boris Gloger, who also mentions the importance of story telling in his book¹).
• Teaching as a one-man-front-show. By keeping those phases short, chances are given that the students actually listen and learn.
• Team exercises that create insight. Those were always timeboxed, and a great chance to improve your skills as a team player.
• Joking to aerate the presentation. Ken is really a master in making use of various incidents for joking, may it be something an attendee just said or a rescue van passing by.

Topics

Topics of this day included the definition of done (there’s exactly nothing left to do), legacy code and the exponential growth of technical debt (which is capable of killing your company), teambuilding, emergent architectures and selling Scrum to managers respectively customers.

Using a squirrel story in the morning and an obviously simple contract exercise a couple of hours later, Ken teached us that it is damn hard to get rid of traditional habits (see the Janus picture at the top of this posting). He also mentioned how simple it is to introduce and how difficult it is to do Scrum.

Fuzziness

Once more I noticed that different trainers and authors teach things differently. While Boris Gloger¹ describes six roles, Ken Schwaber still uses the formula »Scrum Team = Development Team + Scrum Master + Product Owner«.

According to Ken, the Product Owner, as a member of the Scrum Team, should attend the restrospective meetings, a topic also mentioned by Roman Pichler². AFAIR I read contrary statements in other books, and Victor Szalvay writes:

The product owner does not attend this meeting.

As Scrum is a framework, not a religion, such differences do not really matter. It is much more important to internalize what Scrum is all about.

Conclusion

Two intense but worthwhile days are over. It is always a great joy and pleasure to work with people you just met, and Ken’s training style was acknowledge being excellent by the attendees.

¹ Boris Gloger, »Scrum – Produkte zuverlässig und schnell entwickeln« 2011, ISBN 978-3-446-42524-8, page 181

2 Roman Pichler, »Agile Product Management with Scrum – Creating Products that Customers Love« 2010, ISBN-13 978-0-321-60578-8, page 104

Weibliche Ente von Petr Kratochvil

As already outlined in one of the previous postings, certifications do not necessarily tell you anything about the knowledge, skills, or competences of the owner. On the other hand, certificates are usually seen as an evidence in someone’s Curriculum Vitae that she has a certain degree of maturity on the mentioned matter.

After introducing Scrum successfully for my current employer about 20 months ago, the experience I gained since then, and reading some books, I felt it was time to prepare for the Professional Scrum Master (aka PSM) certification provided by Scrum.org. Since Ken Schwaber holds the class in Franktfurt (which is just a trip of about 130 kilometers), there was no excuse to not attend and to not learn from »the master himself«.

Attendees (and Ken) may know why I’ve chosen a duck as the picture for this posting :) . For me, it has a further meaning. A duck is a bird which can walk, swim, and fly. But it is not excellent in any of those disciplines. That’s what I feel about agile in common and Scrum in special. I learned a lot about it, but the more you learn, the more you know that there’s much more you want to discover. While practising Scrum, I always want to learn more »to do a better job tomorrow«.

People came to Frakfurt from several central european countries. The course is held in english language, and frankly, I really enjoy Ken’s style of training. It’s just the right mixture of humor and focus which, combined with the usual team exercises, allows to learn as much as possible. So yes, I’m eagerly waiting for the second day :) .

Companies usually exist »to earn profit to increase the wealth of their owners.«. Ken Schwaber mentiones[1],[2] that Scrum is not a methodology, but a framework for risk management and value optimization by frequent replanning. The key advantage of Scrum is that impediments and dysfunctions which prevent an organisation from being successful are made transparent to everyone, so that they can be addressed and solved systematically. Ken also warns that organisations which do use Scrum not to analyse and optimize themselves will fail miserably.

Overview

Scrum professionals are rare on the employment market. André Häusling[3] mentiones that Scrum certificates are an important ingredient of someone’s curriculum vitae. Thus people may tend to attend trainings, classes, and certifications to boost their market value.

There’s nothing wrong with that, as long as you consider the first paragraph of this posting. Certificates may be the key to enter the market, but in a further posting, André also mentiones that it is important as well that someone has understood and applied Scrum successfully. Boris Gloger mentiones that a certificate does not necessarily mean anything else as that the holder attended a class[4].

The Jazz Musician Metaphor

As a musician who likes playing Jazz and world music, I found a metaphor of Andrew Coote quite interesting. His lightning talk at next week’s »Scrum Safari South Africa« was announced like this:

Using a live performance of a four-piece Jazz ensemble as a reference and demonstration, Andrew will present Jazz as a metaphor for Agile teamwork and the evolution of processes. We work through a cycle emphasising the following common attributes between Jazz and Agile teamwork: Skills, Self Management, Specialisation, Collaboration, Adaptivity, Innovation, Improvisation, Risk Taking, Supporting, Delivering Value, Sustaining Pace, and Passionate Commitment. This is a light, entertaining session that is highly memorable as a metaphor for teamwork.

To ask a provocative question: Would you hire a musician for a Jazz combo just based on a certificate that proves that the prospect attended a class concerning Jazz Drumming?

Learning the Scrum basics

Scrum mainly is a mind set. Before you decide to invest in Scrum, first learn the basics about it and find out whether Scrum fits your personal imagination. If so, learn more about it. Read books, feeds, visit local user groups and conferences to get in touch with people who are addicted to Scrum. Ask yourself whether you share their enthusiasm.

Practising Scrum

Try to find an employer who already implemented Scrum correctly and completely. Work as Scrum developer or as a Product Owner. Learn from your Scrum Master, and start learning about other agile methods (like Lean Production, Kanban, Extreme Programming and the like) as well. Be prepared to help driving the change necessary to make your company as successful as possible.

Scrum Classes

Attending a class will usually teach you the Scrum framework from the point of view of one of the Scrum roles. But beforehand you already should have a clear understanding of what Scrum is. The two days usually used are too short to learn enough to do a good job tomorrow.

Scrum Trainings

If you have good luck, your employer will engage an external training company to ensure the benefits of Scrum will occur as soon as possible. The advantage of an on-site training is that it will not only teach you the Scrum framework, but help your company to implement Scrum immediately and correctly.

Scrum Coaching

In case you took over the role of a Scrum Master with little knowledge about Scrum, you may want to engage someone as a coach who teaches you Scrum. If so, try to find someone who offers a contract with several disjunct training days (instead of subsequent ones) and who grants you the right to ask questions via electronic messages during the period of a year or so.

Certification

I gained my Certified Scrum Product Owner certificate just by attending a class for two days. There were about 30 attendees, and there was no test at all. After the event, I was automatically subscribed as a member of the Scrum Alliance and was able to download my certificate in PDF format. Meanwhile this process has changed so that prospects have to perform an online test.

Additionally, one of the two propellerheads of Scrum, Ken Schwaber, who was a co-founder of the Scrum Alliance also, has founded Scrum.org, an alternative training and certification organisation. His certificates are available as an online test without the requirement to attend a class beforehand.

Boris Gloger complains about both certification processes as being the same and tries to provide an alternative, where added value for the individual and her employer is the main goal[5].

Currently the complete process of gaining certificates is changing. I’m really curious what the market will look like in two years or so.

Conclusion

To become a good Scrum practitioner, some advice from an expert is required. Of course you can try to do it the hard way by trial and error, but it is not really efficient as you will waste some valuable time.

Scrum is about learning day by day, following the »inspect and adapt« principle. Become a good Scrummer before you decide to gain a certificate. In case you pay your certification privately, it is obvious that you need to get a multiple back by an increased salary. But your current (or next) employer will not pay it just because you got the paper. It will only reward you in case you can prove that you are willing and able »to increase the wealth of their owners.«

1 I apologize for relying on german tongue resources

2 Boris Gloger, »Scrum – Produkte zuverlässig und schnell entwickeln« 2011, ISBN 978-3-446-42524-8, page XI

3 Scrumjobs.com, privately owned by Boris Gloger and André Häusling, is a personnel consulting company focussing on agile experts. I am not related to either of them, but from all books I read, theirs inspired me most.

4 Boris Gloger, »Scrum – Produkte zuverlässig und schnell entwickeln« 2011, ISBN 978-3-446-42524-8, pages 4 through 7

5 Boris Gloger, André Häusling »Erfolgreich mit Scrum – Einflussfaktor Personalmanagement« 2011, ISBN 978-3-446-42515-6, pages 81 through 85

In Scrum, at least the two most basic boards should exist, the Product Backlog Board and the Sprint Backlog Board. There are a couple of synonyms for the latter one, like Selected Backlog Board or Task Board. User Stories flow over these boards, using the following approach.

Product Backlog Board

User Stories are the most important ingredients of the Product Backlog Board (though not the only one). A new story typically enters the board after the Product Owner communicated with the Product Development Team, a customer, or a user. A further occasion to collect new stories is the Sprint Review Meeting where some participants have the right, others the duty to contribute new ideas and feature requests.

On our Product Backlog Board, we introduced an area called »Incoming«. Any participant is invited to add new cards[1]. This approach requires discipline, though, as any contributor must accept that the Product Owner has the final saying whether a story will make it to the board – or even not. Remember that it is the job of the Product Owner to maximize the work not being done[2].

A new story usually enters the board from its bottom. The Product Development Team then estimates its size during an Estimation Meeting, and the Product Owner estimates the (business) value of each individual story. The story may move towards the top of the board, depending on the computed priority. Stories at the topmost positions are due to being pulled to the Sprint Backlog Board during the next Sprint Planning Meeting I by the Product Development Team[3].

Sprint Backlog Board

During the Sprint Planning Meeting II the Product Development Team will refine the selected stories by adding tasks to them. Those tasks then will not only tell what, but also how to implement the new feature. Those task cards will be added adjacent to the story they belong to, and move from column to column during the sprint (Due, In Progress, Code Review etc.). After the Code Review, the task cards can be discarded, and the story card will be moved to the »Testing« column. After all remaining tests passed successfully, the user story will be moved to the »Done« column, a very pleasing process for the complete Product Development Team, as it means they have successfully added customer respectively business value to the project. I even read about teams which are announcing this acoustically[4].

Conclusion

A user story usually moves from the bottom of the Product Backlog Board to its top (or it will be removed). This is done by the Product Owner who is accountable for this board.

Some day it will be pulled to the Sprint Backlog Board by the Product Development Team, and it will be refined by tasks telling the developers how the story will be implemented. After all tasks are finished, the tasks will be dropped and the user story will be moved to the testing and finally the done area. The Product Development Team is accountable that this “movement” happens during one single sprint.

1 A Product Owner should always encourage others to contribute to the Product Backlog Board, as it helps the company gaining the best product conceivable.

2 Compare Roman Pichler, »Agile Product Management with Scrum – Creating Products that Customers Love« 2010, ISBN-13 978-0-321-60578-8, page 32.

3 It’s the job of the Scrum Master to ensure that the Product Owner is available during the Sprint Planning Meeting I, and that she prioritized the Product Backlog Board appropriate.

4 Boris Gloger, »Scrum – Produkte zuverlässig und schnell entwickeln« 2011, ISBN 978-3-446-42524-8, page 201

In the world of agile software development, user stories are a common way of creating product backlog items. They are often found in Scrum and Extreme Programming (XP) environments, and often printed to small cards or hand-written on index cards. The advantages of user stories include that they are simple to understand and maintain. In case you are interested in more details, you might as well read »User Stories Applied« by Mike Cohn[1].

Overview

User stories are not necessarily detailed enough to tell a development team what excatly to deliver, but are a good starting point to discuss the feature with the product owner, customer, or (best) user. As a user story can be seen as a feature request, but is no solution request, it describes what to implement, but not how to implement it.

Neither the Product Backlog nor user stories are set in stone. Instead, both artifacts are emergent. Backlog items are »modified, reprioritized, refined, or removed on an ongoing basis.«[2]

Scheme

The scheme is always the same, though there are two flavours.

Here’s the long scheme:

The short scheme is the very same, by simply omitting the part that describes the value:

Acceptance Tests

An important part of a user story is at least one acceptance test, which describes what a user might do using the feature. It may be used by the Q/A-team, the product owner, the customer, or the user to verify whether a story has been implemented as desired. Here is a brief example of a user story containing an acceptance test:

Size

Obviously the abovementioned example is only a rough sketch. Depending on the product being developed and the duration of the sprints, this story might not fit into one single sprint. The Product Owner will know better after the first estimation meeting, where her team mates estimate the size of each particular story, often as Story Points[3]. Maybe the story was estimated with a value of 100, a rather huge measure:

It is likely that the original story will subsequently be split in smaller chunks. The development team then will reestimate the new stories. Maybe those will then read as follows:

Business Value, ROI, and Priority

The Product Owner is responsible to estimate a business value for each story, taking into account various figures. Usually integer values are used to indicate the value that a particular product backlog item is expected to deliver once implemented[4]. The business value is polymorphous, as it may be income, saving money, increased market share, and the like.

The Return On Investment (ROI) is very useful for the Product Owner to prioritise each individual product backlog item. It is calculated by dividing the business value by the size of a story, a value indicating the ratio of the amount of benefit vs. the amount of effort required to implement a particular story.

Stories with high value and small size thus get higher priorities and will be moved from the product backlog board to the task board sooner than others.

Title, Reference

A story can contain a short title and a reference, e.g. in case the index card is linked to an entry of an electronic system, such as a bug tracker. Acceptance tests help further detail the story:

Augmentation

Besides the story and the acceptance tests, stories can contain further information, like more details about the story, hints, and so on. But stories should not exceed the size of index cards.

Conclusion

User stories are the base to communicate features between a project’s participants. Scrum does not require to use user stories, but for many projects, they have proven to be very useful.

1 Some of Mike’s slides are available online, e.g. here and here

2 Roman Pichler, »Agile Product Management with Scrum – Creating Products that Customers Love« 2010, ISBN-13 978-0-321-60578-8

3 Story Points are a series of numbers expressing a relative, not an absolute size, e.g.: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞

4 scrumforteamsystem.co.uk