What should have Story Points?

A fellow ScrumMaster posted the following question on a board on a popular career related site.

I had a discussion with my interviewer about if there is some technical related work( indirectly related to the story in sprint) should have a story point value or not! My thought is 'anything done in sprint should have a story point value.' Any thoughts?

I still believe the purpose of story points is to represent the Product Backlog. The items in the Product Backlog represent increments of Business Value to our customers. I believe that the points are a forecasting tool for the Scrum Team to use historical performance to estimate future expectations. If that is the case, and I am a Product Owner; wanting to give expectations to my customer, stakeholders, and organization, I will want to see decreases in velocity from Sprints were we worked on things other than Business Value that our customer approves of and requests from us.

I do not suggest Story Points for anything except for stories. If you track hours at the task level, then I suggest putting hours towards tasks unassociated with the Sprint goal "on the board" for these types of items. If you do not then you will deliver less of the Product Backlog in that Sprint.


Company Trips

Recently I had the great fortune to take a company trip to Las Vegas. Not to do work. To have a ball. I work at an awesome place. A company trip is not what makes a place awesome. It is many, many things. Valuing its people is one. Investing in their happiness is another. I see company trips in this vein. 

Team building is one of those phrases that has been worn out by its misuse how often it fails to achieve its intended goal. I believe in team building exercises. I think that events where a group of coworkers leave with a better understanding of their other coworkers and a good feeling about their organization is cool to the Nth degree. I think a forced exercise where a team's best memory is that they got a chance to go home earlier than a normal work day has missed the point and is lame. 

A company trip is on the big boy end of a team building exercise. The funny part is that I have only seen small companies do it. I have been a part of two companies that do this. Both were small businesses. I totally get that medium and large businesses cannot do this. Global Enterprises are right out! Can you imagine every Mobil Oil employee stopping work and going to hang out together for a few days. Can you imagine them all descending on a vacation spot? Can you imagine them booking flights? I would love to see that budget and how it impacts the stock market. 

I suggest if a small business does this sort of event to consider a few things to make the most of it. 

Consider your team members in choice of local and activities. There are cultural standards behaviors that would make certain locations and activities better suited to individual teams. My company chooses Vegas and it looks to work really well. We had an opportunity to do almost anything during the days, and we had required team based events at night. I think you can do almost anything in Vegas. I mean that in the good way. Also make sure to evaluate this with each trip. If you experience high growth, your organization may be totally different from one year to the next. What was cool two years ago, may be lost on your current team. 

Allow the team to be part of the planning. Planning a company trip is a huge event and can drive a small group of people or a single individual crazy. I think allowing your people to volunteer to assist with this endeavor is a cool way to begin the team building way before the trip even happens. My company has seen a rapid pace of growth over the past year. Their is a group of leaders that have been a part of the company for some time and take on the responsibility to get it all done. We have recently taken on a really cool Executive Administrator. She is a marvel and did a ton by herself. I saw an opportunity to help and have requested to be a part of this for the next year. I am pretty excited and can't wait to help with it.

Events should be very well explained. As with anything that you ask your teams to do. If it requires clear direction, you should give clear direction. The last thing a team member wants to do is seem like a failure/screw up in front of their team. Directions are also different from goals. Understanding what the we are trying to accomplish is always beautiful. Directions and goals are different from reasoning. Know why you are doing something is a valuable move that has no cost and has infinite returns. 

The more competitive your industry, the more cooperative your events should be. If you have an intense sales organization I suggest events that get your people to work as a team to accomplish a goal. If you have a team based organization that has to do everything together to move ahead I think friendly competitive events are cool. My company is a consulting firm. We are spread across the country. We can take a little bit of competitiveness in our events. Most of our events throughout the year are about getting us together from our disparate locations and clients. I have worked for a highly competitive sales organization where deals where lifestyle altering. Those company trips involved a lot of casual carousing. Even a friendly sports games usually had a bloody something at the end because of the crazy levels of competition among the team members. 

Let them know how big this is. It is my experience that team member sometimes to not realize how much of a big deal it is that a company does the company trip thing. I think the team should know what goes into an experience like this. I always say if you care about something you invest time, effort, emotion, and resources towards it. Let the team know about this investment. I believe that if the team is not aware of this investment, eventually some segment of the unappreciative populace is going to ruin our good thing…

Company Trip.png

My fear of robots, er... tools, pt 5

Online/Offline tools for team project management are expensive. I used to do procurement for things like this. I cringe at the money spent here. I would like to think that no matter if you are at a large organization or a small one, you would will watch spending with a great amount of responsibility. 

Purchasing tools like this goes into the tens of thousands of dollars for even small organizations. This cost is very high. I find this is the case for most project management software.

There are inexpensive an very Agile alternatives to doing things this way. I personally love my card wall. If the wall gets hit by a tasmanian devil, I keep an soft copy in Excel/Numbers/Google Docs or favored spreadsheet application. 


I love team names

I love teams that have unique and colorful team names.

This started with my first Scrum team. I was new to Scrum. I had just sat through my first training class.  It was a training class of around 75 people. There were many teams for a large organization. All of them were new to any type of Agile stuff. I was identified to play the role of a ScrumMaster and was going through all of the in class exercises to support and serve my team. The coach and the VP of Development let us, the ScrumMasters, know that the last thing we needed to do in the class was to facilitate the choosing of a team name. I may be the most forgetful dude on earth. I totally forgot to do this. The next morning all the teams had team names. They were all entered into the software suite that we were using at the time, RallyDev. All of them, except for my team. They were not made aware of what they needed to do. Their ScrumMaster did not let them know. I took on the responsibility and said I would help with it. The VP of Development said that he covered for me and named my team, The Pink Flamingos... I had a team of ladies and gentlemen who were a bit older than me and were all very orderly and hard working. They had a little discomfort with switching to a new way of doing things and a lot of discomfort with being the object of humor for a mistake that was not their fault. It was a long walk across the room to apologize to my team. It was a great bonding experience as they gave me a tough time and sent me back to fix the mistake. We ended up being "The Dingos". Our tagline was "Hide your babies..." This may have been in poor taste with our politically correct society, but it was quite popular and funny at the time. 

I have had a lot of teams with awesome names. I love the bond that the name creates. I love team shirts. I love the connection to product and branding of craftsmanship.

Here are some of my other team names: Grizzlies, Honey Badgers, Ninjas, Pirates, Wolfpack, Super Scummers, The Knot, Red Bull.

I totally suggest doing this. It is a blast.


My fear of robots, er... tools, pt 4

I have a fear of team communication being reduced as valuable interaction is now funneled into tool use.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 

I see this with common office tools like the phone and email. I see teams who are collocated call someone who is outside of their team rooms but located on the same floor as their team for a conversation that may last longer than a few minutes. I see teams email each other when they are collocated. That one is my personal button…

If a team is expected to keep record within a tool they may start to look to this tool as the method to communicate. I have seen team say "Why do it twice?" The tool is often not for them but, if they are judged by what it contains, they may start to use it as the only method of communication. CYA becomes the rule of thumb. I have seen test specialists and dev specialists who sit right next to each other speak to each other through the test case tracking software. Very frustrating…

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.