Ohhhhhh GOD don't even get me started on User Stories... Screw it, I can't help it. OK, PEOPLE. It's called a "User Story." It is an application requirement from the user's perspective. The word "User" pertains to the "person" or "role" that is using the system or application. Now... come closer. Don't be shy silly, come closer. OK, are you ready? THE USER DOES NOT PERTAIN TO A DAMN PHYSICAL SYSTEM NOR PROCESS. YOU MULE HEADED IDIOT!
Oh yeah, for those that know how to properly scrum and write user stories, there are companies out there writing stories like this:
"As a ETL process, I need to send a message to System P, so that it knows I completed my work."
Are you fucking kidding me? NO, seriously, this is happening for real. Stupid IT Project Managers are real! What's the reason behind writing stories like this? This is what they will tell you: Well, we need to be able to estimate tasks for building background processes or setting up the environment.
Listen, don't do that. Stop it. You're embarrassing yourself, your team, and your organization. If someone actually convenced you into doing this, they were highly misinformed, and you need to slap them. If you want to use User Stories, use them appropriately. Their entire purpose is to express clear enough requirements so the development team can estimate and implement them. Anything needed to get the job done is estimated. That includes the background shit. If the team says a story will require 8 story points, then that's what it is. Scrum teams manage themselves. You don't manage a damn thing. Your only purpose is to make sure they have what they need to get the job done and leave them alone. If a user story is too large, appropriately partition the story. Large stories are often 2 or more stories wrapped into one. Challenge the BAs (Business Analysts) to pull out those hidden stories. Everything should mostly fit into its own context. If a story does not have enough detail, your team will let you know.
Don't get so wrapped up into thinking you need user stories to document all requirements the same way. That would be silly. User Stories are requirements for the application. They should not be used for design nor infrastructure specifications.
Let's see... What else... Oh! I almost forgot. Why would you use both Use Cases and User Stories??? Yeah, there are some stupid tards forcing their team to do this. They write stories with the business and rewrite them as Use Cases for development. STOP IT! If you claim to be a scrum shop, then you should be using User Stories! Duplicating work is a classic mistake only good for wasting time. With Use Cases, your team will hate you forever. Why do people hate Use Cases? It is because they are boring by nature, so if the formatting is not beautiful, don't even bother. They don't work in agile practices because they are always written, in non-story-format, by people not doing the work. These peope don't think like development, which means they don't care like development, which means the requirements will be more confusing. With stories, everyone gets it. There is no rigid format. It's just a plain read. You will only put readers to sleep with Use Cases. I'm not talking about the modeling aspect of Use Cases. I'm talking about the boring written requirements. For those that are wondering why stupid managers are allowing both requirement gathering styles, it's because their dumb asses like the User Story sentence structure, but want the details of a Use Case...
WAIT FOR IT...
YOU DOUCHEBAG! Don't do that. Scrum development teams are meant to implement products using the User Story format. If you really feel the need to additionally use the Use Case format, then your stories are lacking clarity. Wowwww, really? Would that be safe? Could I do that? Yes, POP TART!
As a teacher, I need to grade student tests, so their grade average is tracked throughout the semester.
- Allow teacher to select the appropriate test to begin grading students.
- Present teacher with a list of students.
- Student names should begin with last name first (e.g., Doe, John).
- The student list item should display a their current grade average.
- This view of their current grade average should be uneditable.
- The list item should also allow the teacher to enter the student's test grade.
- Allow teacher to save grades for all students in the list.
- Teacher should be able to save grades regardless if they have not finished grading all students.
- Teacher is allowed to finish grading students at a later time.
Thanks for reading. Keep this blog relevant by leading IT managers and actual workers here for laughs, insight, and further debates. Continue to submit your management stories to stupid.it.managers[(at)]gmail.com. Your identity will be kept private.