I have two issues with Scrum in embedded systems. First, there are many tasks to do, especially in the early stages, which are not demonstrable. We started with a development board, no OS, no display, no serial communication, etc. We didn't have our display for six sprints.

The first four sprints were:

  • Getting the RTOS up and running
  • Creating tasks writing network and serial drivers
  • Writing interrupt routines for buttons, communication, etc.
  • Writing the primary database classes and methods
  • Writing a serial debug menu

Most of these tasks are not well suited for user stories. In fact, the only interface into the whole system was the serial debug menu, built in sprint 3, so there was nothing to demonstrate at the end of the sprints. Even the serial menu was meant for internal use and not an end user. Nevertheless, I still want to track and manage these development activities via Scrum.

We ended up writing "user stories" phrases like, "As a developer...", which I'm not happy withm but in using Target Process (www.targetprocess.com), there is no concept of a backlog item which is a task or chore.

Second, how do you handle releases and testing? It's a real pain for us because the testers don't have the hardware debuggers, so we have to build flash versions of the code and burn them on their development boards to test. The testers are not technically as sharp as the developers and often require a lot of support in getting things working in the early stages (resetting the board, connecting the serial communication, etc.), or even in understanding the output.

Finally, regarding the definition of done, a sprint can't be complete until all stories are complete. All stories aren't complete until verified by the testers. There is no way to avoid "robbing" developer time to give to the testers. In other words, if the last three user stories in the sprint will take five days to test, they must be coded and unit tested five days before the end of the sprint. What's the developer supposed to do? Stop working?

I'm being facetious, but it is a real problem trying to conform to the rules. Now, I'm fine with bending the rules, but the issue I have is, it screws up all my burndown metrics if I can't mark things done until they are tested.

I'd love to hear how others have handled these situations.

  • 2
    Step 1. Search for other folks with the same question. Example. stackoverflow.com/questions/5909533/…. It's a very common question.
    – S.Lott
    Commented May 13, 2011 at 18:55
  • It's funny how much time and effort people waste trying to comply with a development process, which appears to add nothing at all to the end results
    – Steve
    Commented Sep 24, 2019 at 6:45

3 Answers 3


You are using a methodology on a product that is not compatible IMHO.

In the way most people define agile, all of the work is negotiable based on changing priorities, re-order-able, or replaceable.

In the way most people define waterfall is that the work is laid out in sequence ahead of time from a significant architecture effort at the beginning.

The tasks you list above seem very waterfall to me. They have to be in a certain order, and they are not negotiable.

I am not saying that you have to abide by anyone's view of any process, but at least for these tasks you seem to be in a non-agile project to me. Trying to bash that into an agile process is going to be a sloppy fit at best.

If the rest of the project is well suited to agile I wouldn't worry too much about the initial setup being a bad fit, but the fact that you mention RTOS and development boards make me suspect the whole thing would be better off in something more like waterfall (a long sequence of immovable dependencies).


OK, so I know nothing about building embedded systems, but from what I can see there's nothing that would make Scrum inappropriate for such development. It's easy to get caught up with worrying about not really having user facing functionality so it's difficult to write "user stories" with having users. Except that user stories aren't really part of Scrum - they're often used with Scrum - but really just as a tool.

What is part of Scrum is the idea of delivering complete features that are fully tested and potentially implementable in a live environment each Sprint. When you're starting from scratch on day one of any kind of a project, the actual value of any kind of functionality you can deliver in Sprint 1 is pretty small. That's because every tiny thing needs tons and tons of infrastructure built to make it work. But the point is that you only build enough infrastructure to make each feature work. And then you build it out as you add more features.

The idea is that you specifically do NOT spend months and months building infrastructure that has no way of being detected from outside the system. Why? Because until you build the stuff that actually does stuff, you don't know exactly what the infrastructure needs to be. That's stuff you learn as you build the actual features of the system. If you build the infrastructure at the beginning, then you're building it when you know the least about the system.

If you're dead set on writing user stories, then remember that users don't have to be people. So you write stuff like, "As a CMOS interrupt handler I need to able to detect the status of the bingle whozzit stack modulation flag when the fluxotronic compressor signals a passive bypass undercharge". Absolutely do not write "As a developer..." user stories.

  • 3
    Good answer, except for the last statement. Developers can be users too, and sometimes you need to do work to support other developers on the team. Commented Dec 4, 2016 at 23:21
  • "If you build the infrastructure at the beginning, then you're building it when you know the least about the system." - it does not follow that an experienced developer will have no idea what the basic infrastructure needs to do. If you built every piece of infrastructure (which by definition supports many functions) only to cope with the immediate problem and without any attempt at foresight whatsoever, you could end up rewriting it endlessly, and may have to keep rewriting the finished features to reintegrate them with infrastructure that is later rewritten to accomodate some other feature
    – Steve
    Commented Sep 24, 2019 at 6:58

You use Scrum in a very specific area and you violate the supposed process on every step. Your question should probably be: Is there another agile methodology which will a better fit to my environment? Simply, it is very hard to help you doing better Scrum if your environment doesn't allow it. The problems I see in your description:

  • No demonstrable tasks which can be considered as infrastructure tasks. If you need several sprints to do something which is not considered as business value then your user stories are probably badly defined. If you need to build a tool or anything else to be able to deliver business value then the product can be divided into two parts / releases - building a tool and building a business value. In such case your user stories "As Developer ..." will be completely valid, because a tool is created for developers.

    The problem here is how to communicate this with customer, because his/her involvement in the first release is zero. If there isn't any business value for customers, how can they participate? How can the product owner define business priority?

    I think that the main problem here is that this is not something that fits to Scrum. Scrum tries to deliver the most important business features first, but you need two months to deliver the first. Scrum and the whole agile embraces the change - what will happen if, after delivering the first features, the customer requires some change which goes back to through all your initial sprints?

  • Testing. Another failure because a team in Scrum is considered as a group of cross functional members. It means that everybody does development and testing and because of that there are not situations described in your final point (or at least not five days long). It doesn't mean that there cannot be separate QA to do some more complex and sophisticated tests, but team must provide an already tested / verified feature. In your case it really looks like Scrum is not what you need. You need separately handled development and testing and passing features between them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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