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.