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.