"Build a Simple iPhone App with Swift" was retired on May 31, 2020.

Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Java Java Data Structures - Retired Efficiency! Custom Serialization

Posted by Adiv Abramson
Adiv Abramson
6,919 Points

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?

Thanks!

2 Answers

Christopher Loyd
PLUS
Christopher Loyd
Courses Plus Student 5,806 Points
Christopher Loyd
Christopher Loyd
Courses Plus Student 5,806 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.

Adiv Abramson
Adiv Abramson
6,919 Points

Thank you for this very detailed and comprehensive response. There are indeed many facets to software development, especially on an enterprise scale. I had a very brief experience in an Agile shop not long ago. One aspect of the process that I found particularly wasteful and tedious was the team meeting in which the programmers were asked to vote on how complex they felt some Backlog items are.

No disrespect intended but I found that to be an incredible waste of time. Who cares how complex someone feels a particular task is?! On a team you have people of varying areas of expertise. Not every team member knows all subjects needed to complete the project equally well. Some programmers may not know network programming, others may not know database access and SQL, others may not know UI design etc. So if I don't know one type of technology needed to do a particular task, naturally I am going to consider it a complex task.

Why waste two or more hours-especially when management wants the project completed by yesterday at the latest-voting on how one "feels" about a particular task? The way I see it, the team leader, product owner or whoever is running the project is supposed to know what his or her team members are capable of, their particular areas of expertise and where there skills are lacking.

To optimize development, the team leader should assign a task to the programmer who is best suited for it. If I am a team leader and the project calls for some table design and data access routines, I am not going to waste time that could be spent doing actual work by sitting around asking for each team member's emotional response to this task. Instead, I know that programmer Joe is an SQL Server maven who knows how to design databases really well. I am going to ask him to do this task and finished. I don't need or want to know that programmer Sally, who simply rocks at front end web development, isn't too keen on doing this task and finds it too complex.

At that Agile shop half of the week is spent in meetings when programmers could instead be coding and producing something of value. How can management expect quick product turn around if it takes away huge blocks of programming time from the programmers with unproductive voting sessions?

Thank you.

Christopher Loyd
Christopher Loyd
Courses Plus Student 5,806 Points
Christopher Loyd
Christopher Loyd
Courses Plus Student 5,806 Points

That shop is doing it wrong then, and their SCRUM Master needs to take charge and action.

According to the Scrum guideline, if you're running two week sprints you should be cutting out about 4 hours for Sprint planning. This is usually done at the end of the previous Sprint cycle.

For example, in my own shop - every other Friday afternoon is cut-out for sprint planning, so that the next Monday (start of a new sprint) we can get right to work.

As far as dividing up tasks - Yes, people have different areas of expertise and you always want to be in a shop that allows you to expand your knowledge.

Lets say for example we have a task that requires some Oracle 11g stored procedure and trigger development. I may not have a lot of knowledge in that area, so to me that story may be a 4 or a 5. However, to someone else on the team it may be a 1 or a 2. The SCRUM Master is likely to give me this 4 or a 5 for my next sprint, along with a bunch of 1 or 2s. This does a couple of things, it tells me who on the team I can ask questions to during the completion of this story if it's assigned to me - and it also gives me the ability to grow my expertise while continuing to be productive with the tasks I've rated 1 or 2 that's been assigned to me.

The point of each developer rating these stories is so that problems that a single developer may not of thought of can come up from other developers, and so the lead/SCRUM master can know how he should divide up the work for the next sprint.

If a lead is only assigning tasks to a particular developers easy scale, then that developer is going to suffer because he's never going to learn anything different, he's going to get burnt out on working on the same mindless development, and no one else on the team is going to learn that given skill. That's the definition of a horrible lead at best.

A good lead/SCRUM Master should be assigning varying degrees of difficulty to all of their developers. Some that the developers can complete very easily, and some that's going to test their skills - that's the only way the team is going to grow and become more well-rounded.

If the team is under a time crunch, then that's different - but then that shows me that the Project Manager failed to communicate expectations of the project correctly to begin with - and that's a whole different issue in itself.

Adiv Abramson
Adiv Abramson
6,919 Points
Adiv Abramson
Adiv Abramson
6,919 Points

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.

Thanks!

Christopher Loyd
Christopher Loyd
Courses Plus Student 5,806 Points
Christopher Loyd
Christopher Loyd
Courses Plus Student 5,806 Points

You shouldn't be planning for 100% development in the first place, that's how all projects are becoming time crunches.

If using two-week sprints, each member of your team effectively has 80 hours of time that can be allotted to them in those two weeks.

We use a method were 20 hours are set aside on bug fixes/small enhancements, 20 hours is set aside for support/reviews/documentation/etc, and 40 hours is set aside for actually writing code.

This gives some leeway when it comes to your development tasks, if you're expecting 80 hours of time to be spent banging out new code, you're setting yourself up for failure.

Additionally, paired programming is a great way for someone to learn, and it's most definitely an option for more difficult tasks for people. Sometimes you hit your sprints right, and sometimes you don't - that will always be an option. If something is "critical" though, to the success of the business then there should definitely be enough time allotted to use it as a learning experience.

Also, about 90% of the things people say are "critical" aren't critical. If this is a new feature or enhancement to a product, it's not critical. If this is a brand new product that hasn't even seen consumer use, it's not critical. Stuff that is 'critical'....meaning, our company will fail or we will miss large amounts of money coming in the door and production would stop working - is usually stuff in the 20 hour allotment of bug fixes.

People tend to scream "Critical, NEED NOW, blah blah" constantly to developers, the team lead needs to make sure he's being a meat-shield to the team though, and sitting down with product owners and project managers and giving realistic expectations instead of fantasies. He should also be putting a hammer to anyone else who's giving unrealistic goals or expectations.

That being said, most of the development I've done has been on automation and process improvement for internal applications used within the company, so my product owners and users are people within the company I work for.

Our process for making sure product owners are held accountable, is every 6 months we go to all senior management for each department within the company, split up the hours we can work for them within that 6 months equally, and they tell us what small/large projects are priorities for those next 6 months. That means THEY have to decide what we work on from the high-level.

For example, let's say this:

  • There are 5 departments in the company needing projects worked on for the next 6 months.
  • We have a team of 3 developers.
  • There are 26 weeks (13 sprints) in 6 months.
  • We allot 40 hours of development per sprint (two-week sprints) per person.

We can effectively tell each department they have about 312 hours of development time they can allot within that given time frame. (13 sprints X 40 hours) x 3 developers / 5 departments

This sets up some wonderful options for the Departments/Product Owners. It allows them to know exactly how much they can utilize our team, and it gives them some options throughout the year.

Lets say Department A doesn't have 312 hours of development time worth of projects for us this 6 months, they only have 112 hours worth. Department B, however, has 512 hours worth of development for us. Department A may make a deal with Department B where they'll give them 100 hours of our time to help meet their 512 hour need if Department B gives them 100 hours of time next half of the year for projects that they know are being started then.

We basically let the Product Owners decide what they're going to do with us, and allow them to wheel-and-deal like an NFL Draft - while we give them the box (allotted hours) to play in. This works wonders, because everyone knows expectations and ends up happy in the end.

In the end, this solves the problem of what is 'critical' - as departments know what other departments are working on, it puts the whole company in scope, and they have to tell decide what ACTUALLY is critical and not what they want to be critical (generally they want everything to be critical).