Scrum Tip: Be wary of how you prioritize

Being a product owner is hard. Making sure you achieve the proper balance of tasks across different stake holders in a product isn’t easy. Support and operations need certain enhancements that make servicing the customer easier, while the business needs to advance with new features as well, and the designer wants to make the user twice as happy by tweaking a few things. All good things, that require good prioritization in order to make a successful product.

So be wary of how you prioritize.

A while back, I started noticing something odd about my priorities. The following scenario kept happening:

  • Monday – Someone asks for feature A
  • Tuesday – Someone asks for feature B
  • Wednesday – Someone asks for feature C
  • Thursday – Someone asks for feature D

On Friday, during sprint planning, the priorities end up being D, C, B, then A. I was allowing the most recent, and loudest, voice win and not some sort of metrics. I didn’t have enough info to effectively weigh A vs D. I was flying blind and trusting the loudest voice, which isn’t a good thing.

When requests to the product backlog come in, don’t take them blindly. Challenge the requester. Ask if they really need this. Push back. Dig into why a request is needed, so weighing it against other requests is possible. If you aren’t challenging your stake holders, you will end up with a backlog miles long that is very hard to prioritize. If nothing else, the process will help you better understand the request.

This is about where I am today. My next step is to follow Dharmesh’s advice, and start weighing different attributes about each request. This way changing priorities don’t completely change the product backlog, they just change which attributes we value the most.

Let me know any tips you might have on prioritization.

Scrum Tip: Sprint length is a variable

One of the nice things about Scrum is the lack of rules. There aren’t a lot. And the rules that are given, should be changed over time. Scrum, like development, is an iterative process of continual improvement. A very important part of the Scrum process is sprint length.

If you’re thinking I am going to tell you an ideal sprint length, you are wrong. My Scrum tip of the day is just to make sure you’re adjusting sprint length based on many different factors.

There are a few very important things to look at when deciding on sprint length.

  • How volatile are priorities? If they change very often, long sprints are going to get interrupted, whether you like it or not.
  • How big is the team? A big team means sprint planning can be very painful. Do you want to have shorter, but more often plannings? Or longer, but less frequent plannings?
  • More meetings. The more often sprint plannings are, the more often demos and retrospectives are. This can quickly drain product owners and stake holders that are part of multiple projects.
  • And the biggie, motivation. Long sprints can have lulls in motivations. Short sprints seem to keep motivation a little higher, and the team focuses more. The power of short iterations to give a team motivation is one of the greatest strengths of Scrum in my opinion. Don’t forget about it

I know what you’re thinking, “great, but how does this help me?”. All I can tell you is what I have experienced.

Smaller teams seem to gravitate towards short sprints, around two to three weeks. Planning’s are pretty simple and quick. The short sprint allows for the team to turnaround things really quickly, and I personally like it a lot as product owner.

Larger teams are the opposite. Even though larger teams usually have more volatile priorities, they can’t stand planning meetings so they space them out more. Most of the larger teams do a 3-4 week sprint.

My tip to you, play around with everything from 2 to 4 weeks. Anything shorter, and you have too many meetings. Anything longer, and priorities can shift too much and motivation starts to slide.

Death of SQL Injection, long live SQL Injection

I very rarely hear people talking about SQL injection anymore. Just a few years ago, it was a very common problem that all developers needed to understand, in and out. My guess is, the prevalence of database abstraction layers in all languages have helped remove this problem from most developers minds. Hibernate, ActiveRecord, Zend_DB, and all the other frameworks in nearly every language are used much more than hand-written queries.

The death of SQL injection.

But wait. The principles behind SQL injection are still valid for any and all applications. Yet, I worry many developers don’t understand them, since the grandfather, SQL injection isn’t as prevalent.

SQL injection exploits a core problem, components don’t sanitize their inputs. Components that use this data to communicate with some resource, like a SQL database, are more prone to bad inputs causing serious problems. But databases aren’t the only concern. REST API’s, file systems, and many more resources can have the same security vulnerabilities.

Imagine a REST API, with the following URL structure.

http://rest_service/<username>/<action>

Your application calls the following action from some web form where username is passed in by the user.

http://rest_service/<username>/get

If the username portion of the URL isn’t sanitized before getting passed to the API, your application now allows REST injection.

Some smart hacker then enters in the username:

brian.hartsock/delete?

Now, your application is going to call the following URL, effectively ursurping what your application is intending to do, just get data, and instead delete data.

http://rest_service/brian.hartsock/delete?/modify

The silver lining is REST isn’t standardized, unlike SQL, so it is much harder to reverse engineer a site and figure out what to inject. The premise is still important though, components should sanitize their inputs, especially before sending them to resources like databases, file systems, and APIs.

UPDATE – Even though REST isn’t standardized, this doesn’t mean it isn’t a security hole. Jay had a good point, and I have struck that line from the record.

Scrum Tip: Don’t underestimate your developers ability to underestimate

Estimating is hard. Developers, at least in my experience, are notorious for making their lives harder and underestimating tasks. No matter how often you tell them to be realistic, it doesn’t happen. There are a few things that can be done to mitigate this.

  • Be realistic about the hours actually focused on development. Many team members, especially team leads, spend a lot of time doing other tasks outside of a sprint. Make sure this is accounted for somehow.
  • Break things down, then break things down further. However you estimate, if part of the estimation exercise isn’t breaking things down to very manageable chunks, estimation is impossible.
  • Quiet planning meetings are bad. In a previous post, I said the team should just have a conversation regarding what the details of the story really are during planning. If this conversation isn’t being had, I bet someone on the team doesn’t understand it enough to estimate. Have this conversation

Lastly, don’t strive for perfection. Estimation is a dirty game that you can get good at, but mastering just isn’t worth. What matters is that things are getting done with quality in a predictable fashion. I have seen a few teams lose focus of what’s important trying to achieve better estimation. Believe me, I would much rather have a team spend an extra day making something remarkable and being a little off in their estimations.

Simple Security Tips

In many startups, the developer of an application is also in charge of managing the server. Since resources are thin, this is how it has to be. Developers don’t always make the best decisions when it comes to managing security concerns on servers though. Here a few tips to you developers in charge of managing servers. Believe me, if you’re successful, you will regret not having followed security best practicies from the beginning.

  1. Go Role Based – Having roles helps auditing, plain and simple. If each user is given their own permissions, you have to audit every user and all their permissions. It is much easier to audit roles, and then see which users are in which roles. This can be accomplished with groups in Windows.
  2. Don’t share – I have said it before, and I’ll say it again, Sharing is for adolescents. Don’t share logins between multiple people. Each user or application should have different, well-named users. They should instead be sharing roles (see above).
  3. Give the least – Remember the time that service wasn’t working for some reason, so you changed it to run as an administrator? Don’t ever do that again. In fact, give everything the least amount of privileges possible. Adding privileges is easy, taking them away is very scary and hard.

Duh right? Well, I bet you have violated all of these at some point. If you follow them when your small, getting big is a lot easier. With size comes auditing and compliance, which shouldn’t be hard but is for all too many organizations. Follow these simple tips, and the day you get audited will be a lot easier.