Category Archives: Agile

6 tips for handling technical stories

The value of vertical user stories seems to be quite familiar for the industry — create small slices of functionality from the users’ point of view, instead of writing horizontal “stories”, that cover only one component of your software.

However, there are times when these vertical slices just don’t seem to be enough. For example spiking new technologies, setting up development environment, enhancing the test framework, improving security, doing major refactoring work… you name it. Here are my tips how you may want to handle these kind of things in your project.

  1. Don’t try to force everything into a vertical story. Based on my experience, having everything as vertical stories is an idealistic state, which in practice isn’t possible to achieve. It’s like defects — you don’t want them, you fix them, but in practice you know that totally defect-free software isn’t possible.
  2. Prefer vertical stories. Having said #1, there is huge value in vertical functional stories, and by default you should always use them. It’s hard at times. If you fail, try harder. Non-user tasks should be used as a last resort.
  3. Have separate metrics for vertical stories and tasks. Whichever tool you’re using, have different issue types for vertical stories and non-vertical tech tasks and measure them separately.
  4. Consider time spent on technical tasks as cost of doing business. If your team isn’t familiar with needed technologies, it probably needs to spike them. Or if there are flaws in the test framework, you may need to spend time improving it. In a way the time spent on technical tasks is a property of the system, and in the course of time it should go down.
  5. Make it visible. For me, the issue with having everything done as a by-product of a vertical story is that it isn’t visible. If you encounter a major refactoring need when implementing a vertical story, one possibility is to do the refactoring  within the story, but then it’s not visible by any means. I’d prefer doing the work in separate task to make it more visible for the team.
  6. Express technical tasks in story format (if you want). You can express technical tasks in story format, if it fits your world and vocabulary. As a tester I need xxx to be configurable so that I can implement test yyy. Remember that these are not user stories, you’re just using story format. And by that I mean that those tasks don’t deliver value to the end user, they are just enablers for the “real” stories.

I do agree with Ron Jeffries that the code should be gradually improved by each vertical story, but in addition to that, there is a need for technical tasks. And there is nothing wrong in using story format in describing those tasks.

Do we need Scrum Masters?

Let’s first revisit what the Scrum Guide has to say about Scrum teams and Scrum Masters.

[…] Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. […]

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. […]

If you’re doing Scrum by the book, the Scrum Master isn’t part of the team, but stands between the outside world and the team. I’ve always found this a bit odd. When I’ve been working as Scrum Master, I’ve always wanted to take part in the development and be part of the team.

In my opinion, Scrum Master capabilities are part of that “competencies needed to accomplish the work”. In the team there should be someone who is naturally interested in agile stuff. Someone who is generally interested in continuously improving the workflow and promoting agile values around him/her. Someone who would be doing scrum mastering even without having an explicit role.

Not everyone has to be heavily interested in soft stuff. The team benefits if there are members with diverse interests. Perhaps one server admin guru,  one front-end wizard, one math expert with algorithm experience — whatever is needed to accomplish the work.

So let’s assume we have perfect set of capabilities in our team. That team has needed capabilities and intrinsic motivation to get stuff done.  Leadership emerges as it’s needed. In these kind of teams we don’t need labels — we don’t need Scrum Masters. Or technical leads. Or server architects. Or … Product Owners?

On the other hand I can come up with reasons to have assigned Scrum Master for the team:

  • If there is no assigned person to fulfill a certain role, groupthink might happen. Difficult questions might not be raised or group handles them ineffectively while trying to avoid conflict.
  • In practice there are always gaps in the team’s competencies. If no-one is interested in process improvement, how does the leadership around that area just automatically emerge? Some issues may not even be handled at all, since everybody assumes that it’s someone else’s responsibility. And nothing happens.
  • It’s might be easier for outsiders to find correct person to talk to. I need to talk about features… I go to PO. I need to ask about sprint reviews… I go to SM.

To conclude: We don’t need Scrum Masters. We need someone (or multiple persons) who has got intrinsic interest in people and process. However, if someone likes to call that person a Scrum Master, that’s fine.

PS. I prefer to call myself Scrum Shepherd. IMO it’s more descriptive. =)

Reasons why I like end-of-sprint Retrospectives

There are people who think that retrospectives should be stopped. I guess the idea would be to have continuous reflection on work processes, in the same way that daily meetings have continuous reflection on the product itself.

I think we should have both. If you have a rock in your shoe, you just remove it. You don’t need retrospectives or reflection for that. If something bugs the team’s work process, just change the process.

On the other hand, I like the idea to have a retrospective at the end of each sprint for the following reasons:

  • For some changes it takes sprint or two to see if it works or not. If you keep changing too rapidly, you might not have big enough sample to really know if the change is needed.
  • People like predictability. As a scrum master I wouldn’t want to shout “hey, let’s have a 15 min extra reflection!”. There is a time and place for people to bitch about the process and make some changes. During the sprint people can expect just to deliver kick-ass software.
  • I prefer to have sprints ending at Friday, and have a retrospective on afternoon. I like the idea of cleaning the table, perhaps even let some steam out, perhaps have a beer afterwards and then starting a fresh new sprint on Monday.

The way I see it, a sprint is lot like a hockey or football match. During the match you concentrate on the game, maybe do some small tactical changes.  After the match there is time and place to watch the game video and make larger changes.


Scrum Master? Transponster?

I love Friends. In one episode there is a scene where Rachel and Monica are competing against Joey and Chandler. If they know Joey and Chandler better than vice versa, they get rid of the duck. Or win the apartment. Don’t quite remember. Anyway, there was one question that I find especially funny:

Ross: Correct! What is Chandler Bing’s job?
Rachel: Oh! Oh gosh, it has something to do with numbers.
Monica: And processing!
Rachel: Oh, well… and he carries a briefcase!
Ross: Ten seconds. You need this or you lose the game.
Monica: It’s, um, it has something to do with transponding.
Rachel: Oh, oh, oh, he’s a transpons… transponster!
Monica: That’s not even a word!

I sometimes feel like Chandler. Hell, it’s hard even for me  to describe what do I do for living. So I decided to gather different kind of activities from past few weeks. As background information, my role is Scrum Master in a team which is building software(*). Half of the team and PO are located outside of Finland. So this is what I do:

  • Have one-to-one video calls with PO about XX
  • Have an initial planning session where we select a baseline story for estimation and arbitrary story point value for that
  • Have planning sessions with smaller groups of people
  • Have a three-way session where we try to solve a technical problem that one person is having
  • Create a single-pager about the sprint goal and stories and attach it near team room door
  • Create tasks for a user story with a smaller group of people
  • Go to Verkkokauppa to get a team room TV, conference microphone etc.
  • Going through backlog and modifying user stories by myself
  • Code a new feature
  • Create unit tests
  • Peer review other team member’s code and documentation
  • Preparing for sprint planning meeting by going through the assumed user stories
  • Write and update a bunch of confluence pages
  • Ad hoc discussions about testing in our project
  • Getting familiar with Git and bunch of other technologies
  • Ad hoc discussions about application architecture and technology choices
  • Have daily standups
  • Have knowledge sharing session where we go through one person’s code
  • Writing instructions about JIRA usage
  • Preparing for sprint review session
  • Facilitating sprint review session
  • Having a sprint retrospective with the team and coming up with a bunch of improvements
  • Participate in session where we go through user personas of the product we’re building
  • Have sprint planning meetings
  • Have sessions about the user interface of the product
  • Have Scrum of Scrum’s meeting
  • Participate on other team’s sprint reviews

…and most likely something that I cannot even remember. So based on this list my job is to talk with people and occasionally produce some code. We’re in quite early stages of the project, so if I would write this list in 6 months from now, the list would probably be a bit more compact.

*) Gosh this is boring as I cannot really tell what we actually are doing. Oh well, at least I can come back to this post after a couple of years to refresh my memories!

PS. Here is a totally not-related nice picture from Pyhä-Luosto 😉

The reason I don’t like #NoEstimates

Based on the first post of my blog one could think that I’m a strong advocate of estimating.  I don’t blame anyone who does, since the title was little provocative and exaggerated. But I don’t have any strong feelings about estimating — the reason I wrote that post is because I have negative feelings towards single-issue groups and hype.  Not just in the field of software engineering but in general, too.


What is common with the above listed(*) items is that they imply that thing X is categorically bad and you should get rid of it. I have one thing to say about that:

Bullshit. It all depends!

It depends on the problem domain, product, organization, team, stakeholders,  process, “agileness” of the people, phase of the project etc etc. I even claim that waterfall model would be perfectly suitable in certain situations and projects.

So, while I agree that planning and estimating are very common areas where there is waste and frustration in projects, I don’t like how that idea is represented and marketed. I say marketed, because the people that seem to be most loud about #NoEstimates seem to be people who get paid for talking, not walking.

(*) I’ve just heard of the first one, made up the rest of them. But if I had to guess, the next hype would be about product owners being evil and you shouldn’t have them. #NoBacklog would be my second guess.

We need estimating!

#NoEstimates seems to be the thing  to practice if you want to be The Cool Agile Guy in 2013. For example Henri Karhatsu has written a great article about estimating and how they ended up in #NoEstimates.

Don’t get me wrong. Most of the posts written about #NoEstimates are solid, golden stuff. It’s just that they quite often miss one quite important perspective:

Estimates = bad. Quite often misused.
Estimating = (usually) good! Can also be misused.

estimatingWhat do you do when you estimate? You create mental models of the possible solutions in your head. You notice too large entities and break them down into smaller pieces. You think about possible pitfalls. Which tools to use. External interfaces. You know, the usual stuff that matters.

I’d like to think that the time spent to think about these things isn’t going to waste.

So if you think about it, estimates are just a by-product of an important process — estimating. You can call it grooming, if you like. Or whatever substantive that best fits your organization. If estimates are required by your boss/organization/PO, just make the journey to estimates worthwhile!

Using the estimates as the basis of decision making is a whole different story, which I don’t dare to cover.