Mans.hu

One of the most common errors I see in sprint planning is the tendency of people to try and come up with story points based on who is going to work on a story.

If the developer is somewhat inexperienced then the entire team leans towards assigning a higher number than they would have otherwise done.

This is a mistake because if you do this you will never be able to increase that part of your team’s velocity which accrues due to the team becoming better at the task.

If a story is truly worth eight points, and you assign it 13 points based on the fact that the person doing the story will take more time then sure this time it seems like the person contributed 13 points to the team, but in reality they delivered lesser business value. Two or three sprints forth if this person is now more efficient and does 13 points worth of work that will not show up in your team’s velocity because you will assign this story 13 points as well. So, while the person did more work from one sprint to the other – the team’s velocity remained the same.

You see this happen a lot, and I believe a big part of the reason is that people are just used to estimating based on the time it will take them, and not based on relative sizing. This is why it is often helpful to remind everyone what the team’s baseline is and that’s to be kept in mind while doing relative story point estimation.

Happy families are all alike; every unhappy family is unhappy in its own way.

This is probably the most famous opening sentence in all of literature. This sentence is also behind what’s known as the Anna Karenina principle.

Tolstoy meant that for a marriage to succeed there should be several key ingredients present such as love, healthy children, financial comfort etc., and the absence of even one of these leads to an unhappy marriage. So, while all happy families look the same, each unhappy family is unhappy due to their own circumstances.

While Tolstoy’s original insight pertains to families – it can be extended to many different things, and I think a happy team is much like a happy family. At present, I’m very lucky to work in a team which is a happy team, but I’ve not always been as lucky in my career.

Image Source: Fanpop

When I look back at some of my unhappy teams I can see several things that made them unhappy, and all of those things are absent in my current environment.

Let me list down some things that I think contribute to an unhappy team.

A bad boss: This is an easy one. There’s a lot of research that shows people don’t quit their jobs, they quit their boss. Tomes have been written on what makes a good boss, and more importantly, you know one when you see one, so I won’t get into the gory details here.

The team is over-worked: I worked on a team that worked weekends for eight straight months. Needless to say we suffered from terrible morale. Our output wasn’t particularly impressive even with all the weekends, and we were much less productive than we would have been if we were working just five days a week. If you know that you have to work on a Saturday then you start slating work that you would normally do on a weekday for the Saturday, and then you whine about it as well. No team that is over-worked can remain cheerful.

The work is not commensurate with the skill: Everyone wants to contribute to the team and do well. But that is not possible if you are being asked to do something you aren’t skilled at. While everyone wants to continuously hone their skills, if your job and skills are at odds you won’t ever be happy in your job.

Being under appreciated: There is something deeply human about the need to be appreciated. Everyone wants to be recognized for the work they do, and even for people who really love what they are doing – the work maybe its own reward, but someone recognizing it surely makes it that much sweeter.

Far too often, people are asked for statuses ten times a day when something is going wrong, but when the obstacle is overcome — no one takes a moment to recognize the ones that made it happen.

Have a lot of this, and people begin to feel they are in a thankless environment, and all joy is sucked from their work. Another aspect of this is trust. Are you being trusted to deliver? If someone is constantly looking over your shoulder and micro-managing you then you can’t be very happy or productive. Most of us have a self image of being competent and skilled in what we do, and micro management causes dissonance, and erodes all the happiness at work.

Doing meaningful work: I’ve been in some projects where the team really doesn’t believe in what they are doing. This can happen for many reasons; once I was working on a project that was going to replace a legacy system that was over twenty years old. What I was working on didn’t even match the performance of the system that was two decades old, and I hated being associated with something that cost so much money, and performed so badly. All of us have an innate need to be part of something bigger than us, and this naturally extends to our work where we want to build something that we can be proud of. It is hard to see how you can have a happy team if they don’t respect the very thing they are building.

While there may certainly be other things influencing the happiness of a team, I think it is a useful way to think about all teams in the way Tolstoy thought about families in an effort to make them happier and more productive.

 

 

 

Often times you need to write a query to list out all issues in a sprint, and the most efficient way to do this is to write a JQL that references the Sprint id.

I am not entirely sure why, but there are times when just typing the Sprint number in the JQL editor doesn’t prompt it to complete the sprint id for you.

In such cases you need another way to find out the id of your Sprint. I know only one way of doing this which is kind of a silly way, but it is effective.

You open the story, and hover over the Sprint Number, right click and “Inspect” as shown below:

 

This will open up the page’s Elements in Chrome, and the Sprint id is visible right there like I have highlighted below.  

 

Not the most elegant way to look for this information, but is certainly effective and quick.