Sunday, May 18, 2014

Global SCRUM GATHERING® New Orleans 2014 - The Product

My last blog post covered some important points I took away from the Scrum Alliance Global Scrum Gathering in New Orleans that pertained to The Team. This was an excellent conference and I learned many new things. Also, practices that I use regularly were expanded and important details were added to my knowledge base.
This post is about The Product. My final post will be for The Scrum Master.

The Product

I focused my session attendance on Product Planning, User Story development, User Experience and Execution.

Product Planning

One of the sessions I attended used the MoSCoW planning technique combined with Size and Dependency of stories.
The MoSCoW technique organizes stories as follows:
  • Must Have
  • Should Have if all possible workarounds exists
  • Could have if not affected by anything else
  • Would like in the future but not necessary now.
We then identify the size of the story using your favorite size measure along with any dependencies.
We identified priority as follows:
  • Small Must Haves are at the top of the backlog, larger stories follow.
  • Dependent stories are included with the must haves.
  • Should Haves and their dependencies are next.
  • Could Haves and their dependencies are next
  • Would like to have are last.
We decide what fits into a sprint or release by reviewing order of the stories in the backlog and their dependencies. Our velocity may require us to shuffle the backlog order to accommodate story dependencies.
This seems to me to be a good alternative to simple drag-and-drop for stories in a backlog. I will look for an opportunity to use this in one of my future projects.

Estimation

The closing keynote was presented by Richard Sheridan of Menlo Innovations. This keynote got a standing ovation and I recommend that you take the time to watch it.
Menlo uses a very simple process that closely follows XP practices. For estimation, they estimate their stories in hours. They use hand written stories and post them on the wall.
The physical paper for each story is folded to represent the size of the story. A 16 hour story is an 8 ½ by 11 sheet of paper. An 8 hour story is folded in half. A 4 hour story is folded in half again.
A planning sheet is used that represents the capacity for a week’s worth of work. At planning meetings, Menlo’s clients place the folded sheets they want delivered in the next week on the planning sheet. 
This simple and unambitious approach struck me as very powerful. It shows what will be delivered and more important, what will not. Watch the keynote to see the details of this and much more.

User Stories

I attended a very interesting session that presented a simple technique for splitting user stories. This very simple technique recommends:
  • Conjunctions – look at connector words like and, or, if ect.
  • Generic Words – look for generic words that can be replaced with more specific terms.
  • Acceptance Criteria – look at a stories acceptance criteria, perhaps it can be another story.
  • Timeline Analysis – pretend a story is done. Review what happens when the story is used. This may lead to smaller stories.
All of these points are available on a single Quick Reference Guide.
It was also recommended that stores be split by a non-technical person.
I also noticed that many people at the conference use personas as a way to define user stories.

User Experience

The topic of user experience came up a number of times. Menlo actually develops separate stories for UX work. One person mentioned the term Lean UX.  A book is available in addition to the blog post.
An interesting point some mentioned about lean UX is using low fidelity artifacts like paper prototypes.

Execution

The opening keynote was by Kenneth Rubin who wrote the book Essential Scrum. He used the analogy of a relay race. He pointed out that we should Follow The Baton Not The Runner. The point here is the deliverable is what is important.
In relation to planning, he pointed out that the reason we plan, is to make meaningful decisions and have a reasonable chance for success. 
Throughout the conference I heard people mention the Last Responsible Moment and Definition of Ready. I plan to keep these concepts in the front of my mind more in the future.




Posted by at No comments:

Sunday, May 11, 2014

Global SCRUM GATHERING® New Orleans 2014 - The Team

I just returned from the Scrum Alliance Global Scrum Gathering in New Orleans. This was an excellent conference and I learned many new things. Also, practices that I use regularly were expanded and important details were added to my knowledge base.
My next few blog posts will outline some of the things I found important. I will also provide links to books and vendor products I found interesting.
I have divided my comments into three categories,The Team, The Product and The Scrum Master. This post is about the team.

The Team

I learned as much from the people attending the conference as I did from the session speakers. This was especially true with the team.
The term T-Shaped Skills was used to describe a cross functional team. The diagram below depicts cross functional ability in an easy to understand manner.


Many times the notion of handling different team dysfunctions and personality types came up. A common idea is to have the team come up with a solution. A tangible way to do this is to have the team come up with Working Agreements and Ground Rules. Since the team came up with the details, when a rule or agreement is broken, it is easy to remedy.
Teams are often uncomfortable trying new things. In this case it is good to point out that we are not sure this will work and that we will Run an Experiment to see. This makes people more comfortable with the unknown.
Distributed teams are becoming more common. This is not just because of offshore teams. More and more firms have their employees spread across the USA.
The points below were mentioned as ways to ease the pain with distributed teams:
  • Tools – there are a number of tools available that allow distributed teams to work better together. See the section on Vendor Solutions below for the tools that were mentioned.
  • Google Spreadsheet – this was mentioned as a collaboration tool because when multiple users work on a single document, the change is annotated with the user’s name in real time.
  • Skype – one person mentioned that they have a computer on and available at each remote location at all times. This allows for easy adhoc meetings when a few people need to meet.
  • Big Monitors Everywhere – one of the best way to provide transparency is to hang or draw burn down charts and other agile artifacts on the wall. With distributed teams, this is not possible. It was agreed that having the charts “available” in a tool is not sufficient. One attendee mentioned that he had big monitors in all locations displaying the agile artifacts. 
I will follow up this post soon with points about The Product and The Team.

Learn More





Posted by at No comments:
Subscribe to: Posts (Atom)