In our company, we are going to deliver a new product which will be used for mass notification, so it is an embedded software project and we are going to use the SCRUM as a framework for the product.
We have started to write down the product backlog. Based on what I understood the product backlog should reflect a business value for each item. The nature of embedded software is that it has a lot of technical details that will consume a large amount of time to create drivers for microcontrollers, like the SPI, UART, ethernet, WIFI, so on.
for example the System is sounding by playing message for notification, so it is pretty obvious that playing a message is a business value but to achieve this goal i have to write down the -requirements which are what also not how – for many drivers like the SPI, MP3 decoder chip driver, SD card driver and finally the FAT, so all of the previous drivers have requirements that should be written in the product backlog, such that the requirements started with a one business value requirement while it has a lot of technical sub-requirements.
These don’t reflect a business value for the client; can someone tell me how am I going to create my product backlog?
9
Where I work, we create embedded systems and are also using scrum for our development. You’re looking at things from a technical perspective, not a feature perspective.
The first thing you should ask is “Why do we need to implement this?” For example:
Why do you need SPI? Is it going to be used for EEPROM so you can store serial numbers? Or maybe hook up to a display controller so users can see items on a display? There are a lot of good reasons to create an SPI driver, but creating it just to have it isn’t one of those reasons.
With Scrum you should be adopting a “We don’t need it until we need it” policy, which is to say that you shouldn’t waste time with SPI or wifi or anything else until there is a business need which requires those technologies to accomplish. Then that business need becomes the story.
Try “Add on EEPROM for configuration storage” instead of “Create SPI Code”
and “Create connection to server for remote management” instead of “Find documentation for WIFI and implement”
5
Don’t get hung up on scrum dogma. Scrum exists to make you more agile. Anything that gets in the way of that can be ignored.
It is true you shouldn’t do work that doesn’t give business value, but value comes in many forms. Do you derive value from having an ethernet driver? I suspect you do, because without it you can’t deliver certain features. “As a developer, I need an ethernet driver so that I can implement the features that require internet connectivity”.
So, don’t look at value only as user-visible features. Value is anything that makes your product better, even if it is invisible to the end user.
Some will say that’s not a valid story, and stories should only have user visible features. I think that’s ok too, right up to the point where it causes you problems like this. Again, the goal of scrum is to help you, and to improve focus and communication. Don’t let what you think you’re supposed to do get in the way of you getting things done. Be pragmatic, and be honest. If you think you need to develop a certain thing, answer the question “why”, and “who is this for?”. The answer doesn’t always have to be the same person.
1
One of the key challenges using Scrum with embedded development, in my experience, is that the best Scrum teams deliver full-stack working slices of functionality. From the deepest guts to the user-exposure. This keeps integration issues within one team and within one sprint. And it proves business value because the end user can see and try the result.
Even for pure software it can be challenging to make the story thin enough at each level so the whole story can be built in a sprint or two. But for embedded, this may be impossible because the deepest guts involve hardware which doesn’t adapt as quickly as software because it is grounded in the physical world.
The ideal solution is to uplift your hardware capabilities so they can cycle faster… with simulators, short-run fast turnaround runs, models, and so on. But that can be expensive. So a compromise often used, which I think applies to your situation, is to relax the concept of business value and let it include more general capabilities that your end users and your application require.
So for example, if you will need to build out WiFi, there had better be an end-user reason or why are you doing it. Find that, and put it in the user story definition, like this one for automotive: “Provide occupant control functions wirelessly, to meet passenger needs while also reducing cost and increasing reliability and maintainability.”
3
I found this link which amongst other things talks about user stories in embedded development (make sure you scroll down to get to the Stories section)
Stories
We will have to look at stories in more depth because one of
the big challenges of Agile development is breaking the system into
the stories that allow incremental and visible progress on the
product. Embedded agile development has even more challenges in
defining stories because of the added complexity of hardware/software
interactions.Stories are usually referred to as User Stories. I prefer to call them
Product Stories. Often the work we do in embedded development is not
visible to the end user. the name Product Story seems to fit better.A product story delivers value, shows progress or reduces some risk
and can be completed within one iteration.