Should I leave building the database for the end?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 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)

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

Answer 4

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.

Answer 5

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.