2

Picture this feature:

Respond to a user from the event stream

The event stream is like Twitter's home page, a stream of messages or events that were triggered by any number of users. The feature is to build a reply feature to one of the messages. Think the ability to reply to a tweet from the your personalised homepage on Twitter.

So in my eyes, this project has many facets:

  1. Frontend Modal Window to Trigger the Event
  2. Permissions to discern whether or not a user can reply
  3. Backend endpoint for submission of reply
  4. Connection to our notification system to tell the message's user that they have a reply
  5. Validation to ensure the reply meets our criteria

How do we break this down? It seems simple, I take those 5 tasks, and I change them into user stories or tasks (whichever is appropriate).

However, in Scrum, using INVEST principles, each story should be at the very least releasable and independent. However, in this case, I cannot do the validation until the backend endpoint and the frontend modal window has been completed, so this fails the test of being independent and releasable. Furthermore, I cannot react to permissions issues until the frontend work has been done, and this would also impact the backend endpoint. Included within this, is the fact that we need the database schema (and the model) for the replies, which acts as a dependency for the entire project.

I'm struggling to adhere to Scrum and INVEST when speccing projects because of how tightly dependent they all are on each other. It's specifically the ability to make them independent and releasable that I just can't seem to fathom. Can someone help?

  • 2
    You don't break it down. As you point out, none of those steps has value without the others. You could have a version where a user can send a message but there's no notification (the recipient has to check back manually) to descope slightly, but that's a discussion with the product owner about whether that would be valuable. – jonrsharpe Jun 4 at 12:28
  • 1
    @jonrsharpe thanks I'd considered this, but If I don't break it down, it breaks the S principle, which is "Small". Since a feature to build all of these facets together is a big one, a mammoth task perhaps (considering different technologies and development skillsets required to complete) – Dan Hanly Jun 4 at 13:06
  • 2
    It's as small as it can be. Some features are larger and more complex than others. You can't have everything all the time; there are tradeoffs. – jonrsharpe Jun 4 at 13:07
  • 1
    its one story, with X tasks. you deliver the story, the tasks can be split any way you like – Ewan Jun 4 at 15:35
  • 2
    "I cannot do the validation until the backend endpoint and the frontend modal window has been completed" - why not? Are you sure there isn't a way to do the gist of it without that other stuff? You (and your team) need to think more flexibly here. Also, be more loose with the term "releasable" - e.g. find some core peace of functionality, and first build a small (and I mean small), self contained demo - say, no GUI and no DB to start with. Figure out how to do something simple, and mock some things. Build the first increment, then build on it. – Filip Milovanović Jun 4 at 18:43
7

I see two possible options.

First, don't break down the item. In this case, the work item (the story, ticket, whatever) represents the minimum valuable delivery of the work and can be estimated by the team and worked on. The team may break this out into subtasks (either in a tool or informally) and work on it, but the work is tracked at the level and is considered done as the work progresses through its life cycle.

Second, break down the item into smaller pieces, each of which can be developed and tested, but may not necessarily be deployable. After each piece, you can confirm that the system is functional (no loss of existing functionality) and you can execute some level of testing against the work done, but the individual pieces may not have value for the end user and may not be shippable until all pieces are done. However, depending on the order of the work, you may be able to also include stubs and give an incomplete picture for stakeholder (perhaps internal stakeholders, perhaps external stakeholders) review and feedback, but not in a production or deployed environment.

There's no one right or wrong answer here. I've seen both be successful.

3

I'm going to lean towards breaking it down.

Yes what they asked for is all of it and they might not find any final use for the parts. I like to break it down anyway. Here why:

At the end of every sprint you show something. That something might be a miserable failure but you show it when you're supposed to show it. That showing gives them some idea where you are. What direction you're going in. And if you've completely misunderstood what they want. It also gives them a chance to realize they didn't ask for what they need.

My first deliverable for this would likely be nothing more than something that could read an event stream. From that I'd learn things. Like if they cared that I was ignoring pictures. It's the things nobody thinks to even ask about until they're looking at something that this helps you learn.

You can argue that this isn't releasable but I'd rather hide this in an Easter egg than go too long without putting something in front of my product owner. Probably wouldn't even have a GUI. Would just dump the stream it saw as text to standard out. Maybe I'm crazy. I also like sprints that are no more than a week long.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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