Are user stories the sole drivers in determining the features, functions and design of an application?
Do any other entities provide input that determines the design of an application? Perhaps an application has to have certain features or perform tasks in a certain way based on company security policies or business rules. The end users who supply the user stories probably don't know about these factors. Does the company itself provide user stories, as it were, that are part of every project?
Can user stories be added once the coding has kicked off or do we first generate an MVP based on the initial specifications (user stories) and only after the MVP has passed testing do we consider new user stories?
What if one user story contradicts another user story such that implementing both in the same project is impossible or very costly? Are user stories ever rejected or kept in the Backlog indefinitely? Who determines which user stories make the cut and which do not?
Christopher LoydPro Student 5,805 Points
This is going to be heavily dependent on the setting of the development.
- Are you building this for another company or are you building it for your company?
- Is this going to be an internal application used by employees, or is this going to be an external application used by the company's customers?
Ultimately, when working on any complex piece of software, you'd want to have Technical Writers and Product Owners come up with a Software Design Document (SDD). The SDD describes the scope and goals of the project, it's hardware/software assumptions and requirements, risks, Architectural Design, etc.
Included in this would be the User Stories and Use Cases. Most people tend to use User Stories and Use Cases interchangeably, but there's a considerable difference. A User Story describes some result or end-goal that's needed for a feature in the application by way of a particular actor.
For Example, a User Story may look something like this:
"As a User, I want the ability to login to Application A via the web"
User Stories are usually defined by the Development Team/Technical Lead as they go through interviews with the Product Owner or get feedback from the users, and with any large development project - these may change, there may be additions, and there may be rejections. The important part is that both the Product Owner and development team is working together to decide these things and there's a general understanding of where the project is and where it's headed.
Once you have your User Stories, these are put into a backlog and the development team has a meeting. Each member of the development team will rate the story (usually from 1 to 5) based on how complex the feel the tasks associated with the user story are, how much time it will take, and any uncertainties to the tasks that may still be lingering.
Use Cases, on the other hand, describe in detail how the system will interact with users or other portions of the system. This includes the initial User Story to describe the result of the Use Case, the Actors involved in the scenario, the Triggers needed to start the scenario, the Organizational Benefits for including the functionality, the Pre and Post conditions for applying the scenario, the Main Course (or optimal outcome) of the scenario, and any alternate courses or exceptions that may come from the scenario (incorrect passwords/usernames on login, redirects to Forgotten Password sites, etc.)
It's important to remember that any software development is an iterative process. Development and Design teams will constantly be going back and forth with users, Product Owners, Project Managers, etc. to refine elements of the software and add or subtract any tasks that's needed - and this doesn't stop once the software has been released either - it's a continual on-going flow - that's what it means to be Agile.
PS - Apologies, as this is a very high-level glance over of SCRUM methodologies and Agile Development, as there are entire books written on the subject that you're asking about.
Thank you for your reply. I think projects are almost always under a time crunch and so I cannot personally justify giving a mission critical task to someone who does know how to do it. If anything, I'd assign the Oracle programming to an expert and pair him with another programmer who doesn't know that material well. The expert would be responsible for delivering the code on time but should give the programmer he has been paired with some easy sections of code to try. That way you get the job done right and a team member starts to pick up additional skills without jeopardizing the success of the project, which is what will very likely happen if a team member is assigned a mission critical task for which he has no clue how to do. In future sprints the process can be repeated with the same pair of programmers or with a different pair of programmers, depending on how far you want the non Oracle expert to progress. The confidence gained by doing small, easy steps will encourage that programmer to want to do more ambitious Oracle tasks as time goes on. But overwhelming him or her with something he or she has no idea how to do and may not even want to do can be a debilitating and soul crushing experience, not to mention a severe drain on productivity, in my opinion anyway. How can I justify to my higher up giving a mission critical task to someone who doesn't know how to do it at all when I have someone on my team who can knock it out of the park without a hitch?
I also strongly disagree with the proposition that a programmer will get burnt out doing what he or she knows best, as long as it's his or her passion. It's only mind numbing if you don't feel challenged or you don't like what you're doing. I for example, love programming in VBA and have been doing so for over 18 years. I am learning other languages as well (hence my presence on this and other code learning sites) to expand my skill set and because I like to program. But I don't get bored doing VBA work because it is my passion and for me it's fun. The Fun Factor aka the Pleasure Principle is something every team leader needs to take into account. Find out what each team member LOVES doing. Find out what he or she considers FUN. Find out what he or she daydreams about as far as work goes. Then exploit that passion and let that team member shine. A team member who's having fun will be far more productive than one who's been saddled with some tasks for which he or she has no interest or passion. If you can turn work into a source of pleasure your team is going to rock big time.