5

Let's suppose that, as a PO, I have a mini-project with my team.
The project consists of displaying messages and announcements on big shared screen. The admin can write messages on a page on his terminal (pc, laptop or mobile device) and the message should be displayed on the big screen for two days.

The confusion for me comes from the fact that I'm not sure if I should ask my dev team to build a DB right away or keep for the last story.

  • US1: as an admin I want to write a message on a new page dedicated for this matter.
  • US2: as an admin, I want to display my message on the big screen.
  • US3: as an admin I want to display my 5 last messages.
  • US4: as an admin I want that all messages be saved so that the last 5 messages can be displayed as soon as the app is opened on the big screen.

Is the US4 useful?

  • 5
    Why does an admin want these things? And how does having (or not having) a database affect the team's ability to deliver these work items? It's unclear how (and why) you're splitting the stories as you are. You also have no hard database dependency called out in any of your stories, so the reason for creating a prerequisite story like building a database is undefined. In short, you have problems with your specifications-as-stories approach that are independent of any database development issues. – Todd A. Jacobs Aug 14 at 15:09
13

It is worrying that you have no why part to your user stories. This is an important element of the user story format as it allows us to evaluate the stories and to prioritise them. It appears that you are writing technical requirements but partially using the user story format.

I also notice that you focus the stories on the admin, when I suspect the value from the stories is derived from people viewing the messages on the big screen.

I can imagine user stories for this project being something like:

As a team member I would like to be informed about activities planned by the admins so that they do not disrupt my work

As a team member I would like to see news from the admins as quickly as possible so that I can react before any disruption takes place

How the development team chooses to implement this is up to them. It seems likely that they will use a big screen and possible also a database. But none of those technical implementation details are relevant to the user stories. However, they may well be relevant to technical tasks relating to the user stories.

  • Interesting, so you think i shouldn't split my stories based on the operations it contains? For instance : As a user, I can manage my account. …I can sign up for an account. …I can edit my account settings. …I can cancel my account. – cascadox Aug 14 at 9:58
  • the two stories you suggested can considered as epics ? – cascadox Aug 14 at 10:19
  • 1
    Exactly, split them based on the end-user value. An epic is typically a story that is too big to comfortably fit in a sprint. So they may be epics depending on your circumstances. – Barnaby Golden Aug 14 at 11:51
  • 1
    @cascadox Yep, the problem with writing "user stories" around technical operations is that they bring essentially no benefit over classical specifications etc. The value of user stories is exactly the focus on what the user is trying to accomplish, not how he wants to accomplish them. It's about motivation, not implementation. Mind, user stories may contain some implementation details, ideally as "technical notes" in their own box - but that's supplemental to the core of the user story, which is what the user is trying to do and why. The user doesn't want to sign up for an account. – Luaan Aug 15 at 9:08
8

US3 and US4 seem to be the same thing to me. If you need to display the last 5 messages, then that means saving them somewhere, so US3 should somehow deal with that. If US3 does, then US4 is redundant and not needed anymore.

But why do you think you need a database?

As the PO you should not care about and/or decide on technical implementation details on your own. You just tell the developers what you need the application to do and they will then decide if they use a database, a file on disk, or something else. If a file can be used to do what you want, then a file can be used. If your requirements cannot be fulfilled by a file on disk, then maybe they use the next best thing, be that a database or something else.

You need to have a conversation with your team. Discuss the functionality, pros and cons of different solutions, any concerns you might have, make sure everyone understands what's needed, then decide together on an approach. The developers then need to be responsible people and - in regards to the persistence technology they use - build a full working solution, one that isn't insufficient in some way, but also not over-engineered in some other.

If you decide you do need a database, you add it when it's needed. You don't leave it for the end, unless it's needed at the end. If you are concerned that changing the database will be costly later on, then it makes sense to add it last. On the other hand, adding it last might cause some issues that you don't see right now, but the developers might be able to spot.

So, the right thing to do is to discuss it with your team and decide together on the opportune moment to add the database.

  • What I'm trying to do, is leaving the database as a last thing. Normally as the project matures the structure of the database will need to evolve, changing the structure of a database is costly. So what I want to say is that it will be more safe to store data using whatever the dev team wants until it's very necessary to build the DB to keep the work going. Should i make this clear on my us ? – cascadox Aug 14 at 9:43
  • 1
    User stories are about having a conversation. You can make it clear in the user story, but that doesn't remove the need for the conversation, explain things, and make sure everyone understands. If you are concerned that changing the database will be costly later on, then it makes sense to add it last. But you should discuss your concern with the dev team and decide together when the best time would be to add the database. Adding it last might cause other issues that you don't see right now, but the devs might.... – Bogdan Aug 14 at 9:57
  • 5
    ... Don't ask strangers on the internet "Should i leave building the database for the end?". Ask your team! – Bogdan Aug 14 at 9:58
  • I'm asking about this to improve my skills, it's not cause i have a real issue on a real project, but thanks ^^ – cascadox Aug 14 at 10:01
  • 1
    You are welcome :) Remember though, that when you will have this on a real project, the right thing to do is to discuss it with your team and decide together on the opportune moment to add the database. As the PO you don't decide technical implementation details on your own. – Bogdan Aug 14 at 10:18
3

There's no right or wrong answer if we just focus on effectiveness, as long as in the end we have the agreed solution built.

The DB isn't even required, one could use the File System writing the users and messages in text files.

The decision is up to the development team to whether or not the DB is developed before, after or during the implementation of the USs. Some developers like to build static content first and make it dynamic afterwards, others like all dynamic right away (I'm considering static content to be the one hammered into the code for testing purposes without going to a DB).

To help with the final decision, one should consider the Definition of Done, more precisely the acceptance criteria of the USs. You won't be able to match all the acceptance criteria, move the user for testing and have it done unless there's the DB (or File System) in place. So, the question is, do you want the users to close the User Stories right away one by one? If that's the case, i would go for DB first (but then again, the decision is up to development team).

About the US4, i can see it useful if we understand the messages to be from all the users. Still, it could stand a some editing to something within that line

As an admin, I want to see the last 5 messages (from all users) once the big screen is opened, so that I get a fast idea of what has been written recently by the other users.

(This would be like a Recent Posts section in a weblog - the screenshot is from my weblog)

Recent Posts weblog

If we understand it to be the 5 messages from the admin, that's quite similar to US3 and you could specify in the US3 acceptance criteria you want the messages to appear right away once the big screen is opened. You can also create USs for each screen and define in the acceptance criteria how it should view. For more complex views, with many features, you might require to break it down into more USs.

The admin doesn't care if it's saved or not, he/she just wants to see the messages.Then it's up to the developers to know what implications it has and express that into tasks (and sometimes speak with the PO to create more USs if some don't exist or others are just too complex and long).

To note: User Stories typically follow this template and only one of yours match it

As a <type of user>, I want <some goal> so that <some reason>.
  • 1
    Precissely because the technical details of how messages are saved are only relevant to the code that accesses those messages, define an API for message management, and let the team use whatever they want for the back end, knowing that it's going to evolve over time anyway. The rest of the code should call this API, and should not know or care about whether messages are stored in flat files, Oracle, MSSQL, or whatever. – Monty Harder Aug 14 at 21:29
  • 1
    Arguably, a filesystem is a kind of database. It has different properties to a relational database, and it's for the team to decide which properties are needed for the project. – Toby Speight Aug 15 at 14:57
2

The requirements tend to define the data structures. If we want to X, we will need to know Y (data). So, you can go ahead and define your stories (from requirements, I hope) and expect the data structures to fall out.

When it comes to implementation, I prefer to work from the inside, out, starting with the data structures (and hardware abstraction). If you do not have the data structures defined, you cannot code the features which use the data.

By all means, leave the actual database till last, if that is what you prefer (*), but if you have not defined the data structures, then you cannot implement the features.

Lack of well-defined data structures is a definite design smell.

(*) make sure it’s preference and not fear. If your team is putting off the database stuff because they are not comfortable with it, you need to aware of that, and allow more time when it does come.

New contributor
Mawg is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
2

Since you are the product owner, you should think of the product in terms of users. Do users care about the database? No, right? Then you should not either.

Your user stories should be rewritten from user's perspective, not technical team's perspective. See below.

US1: as an admin I want to write a message on a new page dedicated for this matter.

As an Admin, I want to be able to write a message in a full screen, so that I don't get distracted by other items.

US2: as an admin, I want to display my message on the big screen.

As an Admin, I want to be able to see my message on "big screen" so that I can ....

US3: as an admin I want to display my 5 last messages.

As an Admin, I want to be able to see my last few messages, so that I don't have to search through the whole list of messages.

US4: as an admin I want that all messages be saved so that the last 5 messages can be displayed as soon as the app is opened on the big screen.

As an Admin, I want to see my last few messages when I open the app, so that I can take a quick look at what was my last message.

As of now, your stories do not contain enough information for anyone new to see what is being built by the team. These stories lack transparency, because I need to understand what is "big screen", "why exactly 5 messages" etc. What you have written currently are the tasks that go in the user story.

Now, coming to the point of database building, it should not be first or last. Any technical artifact whether it is codebase, database, design documents, coding guidelines, functional tests etc are all living things. As and when your user stories are being worked on, database should be modified as required. Otherwise you will not be able to use the learnings in the future stories. This is also why user stories should be understandable to anyone vaguely familiar with the application, e.g. CEO, IT director etc.

So, the short and sweet answer to your question is, "don't focus on when to build database. let the team do that as and when needed". You should focus on just the functionality from user's perspective.

Edit:

Another thing I noticed just now, user story 3 and 4 are actually the same thing. They can both be clubbed as below:

As an admin, I want to be able to preview last few messages so that I don't have to search through the whole list of messages.

Now, you can add "Must display preview on login" as one of the acceptance criteria.

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.