6

Today in our team we faced interesting issue. One of my colleagues wanted to learn basics of some technology which is about to be used in the project. How such an activity should be handled in scrum framework?

Learning task doesn't produce business value. It can't be estimated - for some who know this technology it's 0 story points, for someone who doesn't it can be 13. It can't be timeboxed because we estimate in story points.

How to manage learnin tasks in scrum?

Improve this question

2 Answers 2

Reset to default
8

Treat it like you do with vacation days

If someone needs to learn some things, and they are not working on stories in the sprint, then it's like if they were on a sick leave or in a vacation. When that happens, you decrease the capacity of the team when doing your sprint planning. That means you take fewer stories in the sprint because you have less people available to do the work.

Your velocity will decrease of course, but that's not a problem because it's correlated with a decrease in capacity and not because of any actual issues with the work itself.

Another approach is to use a spike. Being a time-boxed activity, the result will be the same: less work on other stories. So it ends up just like a decrease in capacity.

Keep the training decision transparent and visible and you should be fine no matter how you handle it.

Learning task doesn't produce business value.

Yes it does. You don't learn for the sake of learning, you learn to do something with the new information or skill. To be better at your job. This will reflect in the work you do "post training". Although harder to quantify, it will bring value. Value isn't just stuff inside a user story.

It can't be timeboxed because we estimate in story points.

You have a bunch of things timeboxed in Scrum. The daily meeting, the sprint duration, the refinement meeting, etc. You need slack in the process to improve your work no matter if it's for inspecting and adapting or for training. You can't attach story points to everything, nor should you try.

Improve this answer
2
  • 1
    Thanks Bogdan for good points. Especially meetings as timeboxed things in scrum made me to rethink approach to the framework. Maybe many of us want to be too strict.
    – Arkadiusz Kałkus
    Oct 12, 2020 at 21:44
  • 2
    That's a common occurrence with Scrum. It's often used as a strict process when in fact it's a process framework. It sets some boundaries, and rules to create a context that was shown to help do development better, but within those boundaries you have to build your own practices, your own implementation of the framework. People forget this and think they should "do" Scrum properly, or be careful not to "break" Scrum in some way. For example, Scrum says nothing about User Stories or Story Points. These are additions from Extreme Programming
    – Bogdan
    Oct 13, 2020 at 9:38
1

Interesting question. There are likely to be many answers. In our team we treat as follows:

  • We only move from the Backlog what we have the competence to execute. Internally we move a team member to study a possible new content arising from a demand and possibly be the information multiplier;
  • If we have already started the development and identified that there is a lack of knowledge for its completion, then we treat it as an interruption and stop the task as soon as possible.

In any case, the profile of the professional involved affects the approach - if the technician has preferences or difficulties in the knowledge area, it must be considered so that the learning process can work.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.