Tag Archives: Scrum

Using Scrum to Improve your Everyday Time Management

Scrum is a framework that’s mostly known for its use in Agile software development. In this article I show an approach how to use some of the ideas behind Scrum to manage your everyday activities and tasks, no matter if they are related to product development or not, no matter if they are work related or personal. It can also be a good introductory tool, if your are planning to introduce Scrum in product development, to practice Scrum and develop the discipline to follow the framework on an individual basis.

At first I’ll show some basic concepts of Scrum and then how you can use the information you get to improve your personal planning and time management.

The Backlog — Your List of Things to accomplish

When Scrum is used to develop products you would create a list of product backlog items, also known as features or user stories. This might not directly apply to your everyday activities. For your personal time management I suggest you create a backlog with all the “small” and “large” things you want to accomplish. Things that have some value to you or your organization.

The Sprint — Your (Work) Week

Iterations in Scrum are called sprints. They shouldn’t be longer than four weeks; shorter is better. For your personal time management I would recommend a one week sprint duration. Taking a calendar week seems natural to me.

Oh, don’t let the name “sprint” fool you. It is not about constant rushing. Scrum is all about developing a sustainable pace, which is called velocity.

Sprint Planning — Looking 5 Days Ahead

The first hour of your week you use to plan your sprint. To do so take the top items from your personal backlog and assign them to your sprint. At latest at this moment it should be clear to you what it means for you to call your backlog item “done”. Then break down your weeks goals into tasks. Ideally tasks shouldn’t take longer than a day, but definitely should fit into your sprint..

All your tasks should have durations in hours associated by now. Again, it’s about developing a constant pace. Let’s say you are planning a 40 hour work week, but maybe you have to go to a bunch of project meetings. In this case plan only 35 hours worth of tasks. Don’t overthink how much time you will spend on “your” project at the beginning of your sprint. If you use it in a more constant pace, you will be able to identify you average time after a few sprints. But even, if your effort varies a lot per week, e.g. you use this for a project at home and family activities don’t allow you to put the same amount of hours into your project every week, this is more about your time management and (short-term) planning.

The Daily Scrum — Your Minute to reflect

Agile teams get together in the daily scrum to briefly talk about their accomplishments since the last daily scrum, the plan to the next daily scrum, and their impediments. Of course I’m not suggesting that, you stand up and talk loud to yourself. But I suggest that you spend a minute or two at the beginning of a day or work session to review your past tasks, ensure your upcoming tasks are lined up properly, and that you identified any possible impediments, and you have a strategy to overcome them.

The Backlog Grooming — Review your next Goals

Once during your sprint, maybe roughly in the middle, you could go through your backlog and review the priority of the items in the list and maybe break down larger items into smaller chunks that can be accomplished within on sprint.

The Sprint Review and The Sprint Retrospective — Recap your Week

While Scrum teams present their accomplishments at the end of the sprint the their stakeholders and review the sprint to improve their processes, in this adoption of Scrum you are your own stakeholder and your own critic.

This is the moment for you to learn and improve. A few questions that might help are:

  • How long did it take me to complete my tasks compared to my original estimates?
  • How many tasks was I missing?
  • Did I clearly understand what “done” meant?
  • How many hours was I working on tasks compared to other activities like meetings or training?
  • How much time did I have to work on unplanned “emergencies”?

Looking at these questions can give you a better understanding of how well you estimate your work. Over time it might enable you to get better with your estimates and allows you to improve your commitments. Working of a prioritized list gives you focus and can help to meet the right objectives.

As I mentioned at the beginning of this article it was targeted to your personal work or activities. If you use this in a business and you might be part of Agile project teams, you don’t need to manage your activities double. You can use this, if at all, for your commitments outside of the project, e.g. Department related work, or to manage your continuous learning objectives.

A last comment is towards tools. For yourself you don’t need difficult or expensive tools. A few simple lists in a text or spreadsheet application can do the trick. Even a piece of paper that puts your weekly objectives and tasks in front of you will work. But if you want to use special software that can help you with managing the above mention activities, you can find some that offers these and other tools for free for small teams.

I hope you liked this article. In any case, I would like to hear from you.

Scrum in Medical Device Software Development – Three Critical Aspects

Many companies that develop software for medical devices, including for in vitro diagnostic devices and active implantable medical devices, are still struggling transitioning to an Agile software development process. Assuming you know how to develop software for medical device in the waterfall lifecycle model transitioning to an evolutionary (or spiral) lifecycle model does not take too much.

The Agile Manifesto is often misunderstood and misinterpreted that processes don’t exist, documentation doesn’t get created, and no plan will be followed. When the following three critical aspects are considered your are on the right path to succeed in your Agile implementation.

1. Definition of “Done”

Scrum teams are self managing and self organizing teams. Not the individual, but the team as a whole, is responsible for creating a potentially shippable product at every increment. Which doesn’t mean the team can decide alone what they do, but more how they do it, and who does what task. In the regulated world of software development for medical devices the “what’ includes critical elements like risk management tasks and other process requirements as they might be described in IEC 62304. Every product backlog item (aka. user story) should have a clear agreed on definition of “done” describing all relevant process elements and process outputs.

I collected some considerations what could be part of the definition of “done” for backlog items in a checklist.

2. Transparency

Every iteration should end with two meetings. First a sprint review meeting and then a sprint retrospective. During the sprint review meeting the team demonstrates to the stakeholders what was done and what not and answers questions. The team and the stakeholders collaborate on what could be done to optimize generating value in the next iterations. And please don’t forget, in the regulated software development compliance to the regulations and international standards is also value. Since management could belong to the group of stakeholders it gives management frequent opportunities to work with the teams and to ensure important business needs are met. The second meeting is the sprint retrospective where the team is amongst themselves and discusses issues and how to avoid them in the future. In following sprint reviews the stakeholders could see the improvements.

3. Discipline

One less obvious aspect is discipline. Under schedule pressure team might lead to making shortcuts. The scrum master should work with the team on not giving up on the best practices and agreed on objectives, and much rater adjust the scope of an iteration and do less. Keeping the technical debt low and quality high allows agile teams to continue developing high quality products at a constant pace.