9

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?

Improve this question
9
  • You should break your problems down into smaller steps, just like you should break your paragraph into multiple sentences. If you can't break your problems down into smaller steps, then maybe scrum isn't the way to go. Commented Feb 19, 2014 at 13:49
  • 1
    You may find that for embedded development, some tasks (like those drivers) will be larger than commonly recommended. This is sometimes unavoidable and you will have to live with it. Commented Feb 19, 2014 at 14:15
  • 1
    The problem is that you are focusing on how you want the results to be achieved. This just doesn't work in agile. Focus on what your customer wants, starting from the basics, and then slice these features vertically without specifying how to achieve them. The point is not "write a driver" but "what does our customer do with a driver". Commented Feb 19, 2014 at 15:25
  • 1
    I have serious doubts that Scrum is the best approach for Embedded systems. You can do agile based on scrum, not Scrum. My main concern is around Scrums concepts colliding with the real world of hardware development lead times and cycles. Have you considered other Agile methods? Commented Feb 20, 2014 at 1:59
  • 1
    @Blrfl, yes, the problem of expressing that something is necessary to deliver business value, but not, on its own, sufficient for it. Many products realistically are only valuable as integrated wholes, where their value can be quantified by the fact of their sale, and worthless (or near-worthless) as parts. Commented Jan 5, 2018 at 22:02

4 Answers 4

Reset to default
13

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"

Improve this answer
5
  • 3
    What do you do if (a) adding SPI handling code is quite complex (ie. around as many points as you could handle in a sprint, maybe even more), and (b) there are several user stories that require SPI handling code? Commented Feb 20, 2014 at 4:50
  • actually this is my concern which will lead to a punch of technical requirements that are inherited for one business value requirement. So at the end the product backlog will contain a lot of technical requirements which aren't a business value, Is it acceptable or am i violating one of the agile concepts? Commented Feb 20, 2014 at 6:37
  • You shouldn't get too hung up on the tenants of agile. as Bryan said, you shouldn't get too hung up on the dogma and just do what works for you. My main point here is that you should just try and keep the business value in mind. What you do may not add business value directly at the end of the story, but it should lead towards that goal. Commented Feb 20, 2014 at 17:55
  • 1
    Extreme example playing devils advocate: What happens if I don't do the SPI interface because I don't need it (Scrum dogma), then one day, I do need it. I implement the SPI and find a hardware defect. Ignoring that I might have shipped hardware already, the lead time for the fixed hardware is 6 months (quite common) but Scrum required me to implement just before I needed it. Whats the Scrum solution to this? Commented Mar 13, 2014 at 20:35
  • @mattnz This is a bit late, but the scrum answer would be that you should have a business interest in shaking down hardware defects early, and exercising the SPI interface early would have a business value. You have to pay attention to your actual needs, which is not always a simple naieve process. As with all workflows, a naive implementation of Scrum will fail. Likewise, a naive implementation of EVMS or any other heavy top-down approach will also fail. Commented Jan 6, 2018 at 6:25
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.

Improve this answer
1
  • What was Scrum dogma in the original question? Misinterpretation is not Dogma. Dogma would be if Scrum had practices that were inapplicable. Commented Mar 13, 2014 at 14:28
3

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."

Improve this answer
3
  • I never think the automotive production analogy with software is very apt. Cars have had a fairly settled design for a century, and are built only by the largest companies who create and retain experienced specialists in all kinds of fields. Anyway, cars nowadays are subject mainly to bolt-on features and minor refinements, not designed and built from the bottom-up, and design changes still take years. Software development really bears little relation to the car business. Commented Jan 5, 2018 at 22:14
  • 1
    @Steve he’s not making an analogy. He’s giving an example of a story you may find on an automotive team’s backlog. Commented Jan 6, 2018 at 0:53
  • @RubberDuck, I think he must implicitly perceive (and intend the reader to perceive) some analogy with the automotive production or similar manufacturing process - exactly what the analogy is perceived to be may be unspoken and under-defined, but that doesn't mean it's not an appropriate time to remark on and refute the analogy, and how processes employed in manufacturing are used within quite different circumstances and conditions than exist for much software development. Commented Jan 6, 2018 at 1:41
1

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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.