User story in a Datawarehouse context

Are these user stories prompting good discussions about the underlying requirements that ought to be satisfied?

It sounds like you are trying to make a number of decisions for the Scrum Team.  I'm assuming you are filling the Product Owner and Scrum Master roles. (In my opinion not a good idea but I won't go into that right now.). Why are you not involving the Developers in the process of creating the user stories?  In my experience, the Product Owner usually starts with a high level description of the problem that needs to be solved with information on how to know it is solved.  From there, the Developers get involved and refine the original problem statement into items that can be addressed during a Sprint time box. 

How you should write these stories is not something that we can provide as we are not involved in the situation.  The "right answer" should come from discussions that occur within the Scrum Team to determine how the work items need to be organized and what information is needed.  Also, remember that you will be iterating on the solutions so you shouldn't try to anticipate too far into the future.  Create work to get started and then fill in more items as the work is progressing. 

Well, I said that I wanted to implement Scrum because right now, we are in a very "traditional" way of working (V cycle without proper spécification) and no one has really heard of Scrum (IT juste know général ideas of Agility and business nothing). The platform and first datawharehouse have been done in V cycle and I arrive after 6 month of pause because the business lead quit the company so no new business requirement were created... 

So, yes, for now, aside my work to collect the needs from business domain, I try to do the SM role in order to initiate this scrum initiative. This example aims to give an example of backlog and PBIs. And I will  set up a presentation of scrum in a 2h meeting as a starter... No real formation is planned because upper level have not yet been onboard but the IT data team lead agree with me to try the scrum framework. 

I have a business personn that could (should) be PO but he will just validate the kpi definition & prioritize between domain (finance Kpi 1 rather HR kpi2 for example) so I'll be ProxyPO to do the prioritization with it data team (my position is IT side) .

More over, the data sources IT teams are not in the future scrum team so I'll interface with them with the data It lead to define what data will be in the feed. That why I was thinking of creating 1 user story by data feed because we will be dependant of the answer of external team... 

Objectif is to have quick wins in order to persuade the upper level to have some budget to have a real basic training of the IT team (none for my PO since I will work for him as proxy) and to get a tool because my nose tells me that managing the sprint backlog and visual board with Excel from scratch is going to be painfull...

Thank for your answers ! 

Do they need to be user stories? Would it be easier if you didn't try to do the user story form?



Also, maybe not all requirements need to be in the "title" of the item. You can maybe write a sort of summary "User can view KPI 1" with in the comments/description/acceptance criteria the rest of the requirements?

Part of the solution to this problem is the Definition of Done. Do you have a DoD, can you comply with the DoD with these PBIs? As an example, "The functionality is added to the top menu" can probably not be complied with if it's a stored procedure in the database?  Make a DoD that fits the PBIs you think you want to make. If you can't write a proper DoD for all of them, they are not good PBIs and you need to write them differently.



On the topic of splitting up PBIs: Is it true you can't do the complete functionality in one PBI? Is it truely too big for the team to get it to Done in one Sprint? For the Team? They can make tasks to divide the PBI in smaller units, they can work together on one PBI. Limiting the Work In Progress is one strategy to have the team work together and share knowledge, and at the same time makes scientific management more difficult (aka: count up and compare the performance of the developers).



Discuss all this with the Developers and the Scrum Master, that's what refinement sessions are for. When I wrote "you" I meant "the Scrum Team".

i am having the same quandary.  have found a lot of story splitting advice that is useful for application development, but i have been looking for story splitting approaches for DWH (data ware houses)

i understand two things

1. not to have a monster story , but split with a view to complete smaller stories in a single sprints

2. not to have technical stories.

So at moment, our team split a monster story into technical stories that can be completed in different sprints. I agree this is not good, so am after ideas. We are a Business "Intelligence" / DWH team where a typical example

--> (a) is waiting for a source system to capture new data

--> (b) we amend ETL for BI datawarehouse

--> (c) we update a PowerBI dataset data model

--> (d) we publish new PowerBI report that provides the actual business value.

obviously (d) is the user story, and (a) (b) + (c) are technical tasks that will be spread across sprints.. Open to any ideas about how to split this story into User stories. These two apparently conflicting principles are causing a lot of unresolved debates in team

Scrum is about generating Value. I suggest structuring the Product Backlog in such a way that there is transparency around Value.

You may want to discuss this with the PO regarding how the product generates value. How this value can be measured?

 "As a manager, I want to have a dashboard with KPI 1 over month in order to manage the operational activity"

What is the Value of this PBI? How do you measure it? Maybe you can measure the time the manager saved because he doesn't need to search for the data manually thus he can focus on something else. Or maybe the sales will increase because the manager can optimize the flow thanks to this data. Or maybe actually nothing will change besides that we have a nice dashboard?

So at moment, our team split a monster story into technical stories that can be completed in different sprints. I agree this is not good, so am after ideas. 

Will the technical stories provide value if they are completed? Why would that be "not good"?  The goal is not to deliver a feature.  It is to deliver value.  That value should be visible to the stakeholders.  Here is where a lot of people get confused.  Stakeholder does not have to mean the end user.  Another team could be a stakeholder for a story if it enables them to deliver their own value.  The team doing the work can be a stakeholder as well for much of the same reasons.  Don't focus on how long it takes to complete a Product Backlog Item or the way it is written.  Focus on whether that Product Backlog Item will provide value to a stakeholder and incrementally approach the ultimate goal. 

I need to push this topic because I have a very similar issue. 

The goal is not to deliver a feature.  It is to deliver value.

In my understanding each Sprint should result in an usable increment that meets the DoD. 

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

In order to provide value, the Increment must be usable.

With my team, we have similar steps like Steve. Before the user can see even the smallest chunk of data, model has to be created or extended, it has to be fetched, migrated etc. into our own database, before Frontend can connect the endpoints und business can actually test the functionality. When successful, it is considered "done". 
The problem is, that all the data work is necessary, but can't be tested until most tasks are completed and therefore can't meet the DoD, aren't releasable and therefore doesn't count as an Increment. And the needed work can easily extend our two-week Sprints.

What we do sometimes is to build Frontend UI using mock data, but that feels a bit of cheating, since it is not really end-to-end functionality (although might work as a "teaser" for the customer). 
I could also easily extend our sprints to four weeks, that would definitely be enough time for our devs to finish work to our DoD, but that also feels a bit like cheating. 

I really invested much time in finding a solution for this, trying to brake down user values / stories, but most examples simple doesn't apply to our problems.

 

Before the user can see even the smallest chunk of data ...

Where in the Scrum Guide does it state that the user has to be able to see the change?  It states it must be usable. It states that it must meet the Definition of Done.  But it never mentions the "user". It does mention stakeholders though. 

The Scrum Glossary on this site provides this definition:

Stakeholder: a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.

In the case you described, I used this part of the sentence used previously to identify the proper stakeholder for you.

...before Frontend can connect the endpoints und business can actually test the functionality.

Is that a separate team?  Could your Frontend team be the stakeholder for your team? In your Sprint Review, they would be the stakeholders that provide you feedback since they are the consumer of your changes. 

Frontend is not a separate Team, I would say that we're as cross-functional staffed as possible for our case to provide ent-to-end functionality and development. 

But what I do understood is, that finished PBIs are not needed to have a visible impact, as long as they're not breaking regression, for example. 

But what I do understood is, that finished PBIs are not needed to have a visible impact, ...

Not every item in the Sprint Backlog has to produce noticeable output.  It is not uncommon to do some pre-work that is needed in order to implement features or to buy down some technical debt.  As long as the application is still usable and the item meets the Definition of Done, then I encourage teams to do this kind of work.  If there is doubt about the application still working, put the new code behind some kind of "feature flipper".  Implement code so that the new code will only execute if a specific flag is passed/set. My last organization did this a lot by passing in a parameter on the url. It allowed us to push code to production and test it there.