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 dev board, no OS, no display, no serial comms, etc. We didn't have our display for 6 sprints.
The first 4 sprints were:
- Getting the RTOS up and running
- Creating tasks Writing network and serial drivers
- Writing interrupt routines for buttons, comms, 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. Never the less, 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 with 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 dev 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 comms, 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 3 user stories in the sprint will take 5 days to test, they must be coded and unit tested 5 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 their tested.
I'd love to hear how others have handled these situations.