I’m currently doing the tribute page project, and it’s been pretty simple so far. However, step 2 of the project says to “fulfill the below user stories”. I’ve googled “user story”, and kept getting something about agile software… I think it’s like a review or note of some kind, but I’m not really sure.
1 Like
I see user stories as client’s requests for the project.
For example in this project https://www.freecodecamp.org/challenges/build-a-javascript-calculator. The client needs to be able to make basic math operations, clear the input and chain multiple math operations until they press the equal button.
From Wikipedia
In software development and product management, a user story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system.
2 Likes
Yeah, that was a comprehension speed bump for me too - I’d never heard that term. Just think of it as a “list of things the user needs the app to do”.
So I don’t actually need to write anything extra?
No, those are just guidelines for what the code needs to do. You don’t need to write an essay or anything. Just think of them as “code criteria” or “things the customer wants”. You will “answer” them by writing code that fulfills them.
Yes, I agree, “user story” is a confusing name.
1 Like
Yeah, I wonder if the term (User Story) is actually came from Scrum.
I understood them as the minimum amount functionality and/or design that the project should have after completion. If you look at the sample projects, they often have more function / design than what just the user stories specify, however anything above and beyond the user stories is discretionary, of course, it goes without saying, the more you do the more you learn.
I thought the same thing lol
I’ll tell you what, I’ve noticed there’s allot of “jargon” in Computer Science (we’re in that realm Admin?) but it’s for good reason.t
The jargon’s there because allot of what we (including you) do is so different and are part of ideas that are so unique they need brand new words.
Now, I think some of the words are friggin stupid/illogical e.g.:
- shift
- unshift
- push
- pop
…push and pop are cool but I feel they’re use din the wrong way. But you’ll use them all.
I think FCC made up “User Story” though :laugh:
According to everyone’s favorite online, user created encyclopedia, the term dates to 1998 and has been used in programming since at least 2001, long before FCC existed.
It is a confusing term, though.
1 Like
ROTFL
I knew one of you guys were gonna do that
ROTFL
Don’t speak to aaaaaanything else I said though lolol
Aw man this is the best place.
Also, your comma should come before the word encyclopedia. Since we’re correcting each other.
No, commas separate coordinate adjectives in a list, but never go before the noun they modify.
From Purdue OWL
- Use commas to separate two or more coordinate adjectives that describe the same noun. Be sure never to add an extra comma between the final adjective and the noun itself or to use commas with non-coordinate adjectives
“Encyclopedia” is the noun. The comma after “encyclopedia” is to offset the dependent clause from the main clause.
As a grammar tutor and proofreader, if I were to criticize anything in that sentence, it would be that “user created” probably should have been hyphenated.
Beat me to it 
Though I agree the terminology might sound ‘a little corny’, ultimately its odd phrasing is actually rather important as towards what it intends. I think it is worth taking a moment to be specific about this-- Particularly that the story is defined in terms of the ‘users’ perspective.
The way I like to think about it is if one were to take a targeted, but perhaps not (necessarily) tech sophisticated targeted end user of your application and ask them: So, what does this application do ?
And, I believe, ‘ideally’ the end user should be able to describe back something closely approximating the ‘user story’.
This is why, especially coming from a larger scale team Agile environment thinking of a ‘user story’ just as a feature is a misnomer. Maybe, as a (smirk) diligent programmer you have implemented the ‘feature’ to provide this sort of function-- But your UX designer has in turn buried it so far down, through menus or obscurity, that that functionality is not readily apparent to the user. The programmer might come back and say ‘but !’-- And just in the same regard, the well meaning programmer may have implemented it as a ‘feature’, but for what ever reason, even with good effort on the design side (maybe just the way the code is written means the end user also needs a PhD to use it)-- This also fails the ‘user stories’ test.
I know it sounds a little odd, but at least in the context of ‘teams’ I can certainly see where such a term came about.
As to whether one should succeed or surpass it-- In the real work place this really ‘depends’. Obviously for one you are directly being compensated for your services, so these should be the tasks you should seek to accomplish ‘first’. Of course many other design factors come into play and your experience as a developer, knowing competing projects, will give you some sense of leeway and also know when it is time to ask for guidance.
Though generally my experience has served me well in this regard, there have been a few times when I have been ‘burned’-- And I don’t think I am alone in that, but even if you have another feature that will totally blow away the competition, or even offering up potentially worrying ‘security concerns’. Well, you’d be surprised at the number of times what really is unexpected, for the handful that might like it-- The customer might hate it, even though you never meant it that way, or might not understand or agree with your concept, or your boss might think you are somehow stepping on their toes, there are actually any of innumerable ways it could end ‘very badly’.
I’m not saying ‘stay quiet’, but I learned the hard way in the work place at least once-- Honestly every other job my extra effort was always appreciated, but in much larger companies it can be unexpectedly different.
As to the FFC projects, it depends on your goals: As any ‘employee’, you can satisfy the stories at minimum and justifiably earn your certificate. But the real point of these projects is not just ‘solo’ work, it is also to have a minimum portfolio for presenting to employers for opportunities for work.
Given FCC has, as far as I am aware, a particularly ‘unique’ open style towards both content and projects, even under the new beta model, that moment when you have the chance with the recruiter it is not just ‘I completed XYZ projects’-- Rather, I can easily point you to the ‘comparable’ projects of my classmates (I mean just do a CodePen.io search), and these are the reasons my work is unique/different.
At the same time not to discourage or ‘intimidate’ anyone in that regard-- If you see someone else’s project where they did something neat, ask them how they did it. Your project does not have to be the best in all ways to find someone respectable to hire you, but you should be able to find some unique advantage, based on your own skills and experience, as compared to other developers, and somehow describe that to a prospective hire.
And I actually encourage you to do that, check out the other competing projects on CodePen. I was looking at a few tonight thinking ‘I wouldn’t think of that’-- Or ‘that effect is cool’.
So… if FCC really needs to code a term, let’s call this investigation, project planning, and explanation of why one is unique the ‘Developer Stories’-- Are we all better now ? 
1 Like
It’s the story of a user’s specific journey through the app, hence “user story”. You make up a model user, then describe what they should do to fulfil some goal.
It’s not a new thing, product design people had used the same processes for years before it was co-opted by Agile folks.
It is designed to avoid very specific written requirements, a tool to get developers to think and talk about how best to implement something. It just describes some behaviour that should occur in a series of steps.
As a [kind of user], I want [to do something] so that [something will happen].
It’s at a specific level, with a specific user in mind - small discrete steps, but not how those steps should work technically. Not an overarching life goal (user wants to enrich their life) - that would be the business case for an application. Not an overall goal (user wants access to an electronic calulator) - that would be called an ‘epic’ in Agile, an umbrella for a collection of user stories. And not specifics regarding technical implementations.
It means programmers and non-programmers can have a conversation about how an application should behave. That specification is then used to test that the application works (GIVEN the user has entered an email and password AND the email/password combination has been validated THEN redirect to the user's account information page). The tests are either manual (following the steps), or automatic (converting the steps to automated tests). Tools like Cucumber allow you to write a set of user stories and then run those as functional tests against the application (Behaviour Driven Development)
2 Likes
That makes sense to me now. Tx.
1 Like
That Also helps me better understand. Tx.
is it necessary to follow all the user story’s given?
I have made the project in my own way and submitted it through GitHub Pages url and it is accepting the code.
what should i do ?
should i recreate my project according to the ‘User’s Story’?
For FCC’s certificate, the test script should be included, with all tests passing, when you submit your projects. In order for all tests to pass you have to follow the user stories.
You can create a similar page that doesn’t follow the user stories exactly to showcase on a portfolio that’s not part of the FCC curriculum if you’d like.
When you submit a project there is no testing that is done to it.
The user stories are there because it’s a way of checking that students can do the basics that are required for the project.
In the real world, think of user stories as customer requirements. They’re there because that’s what the customer has requested. If you do it your own way, you won’t get paid.