Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Search the Community

Showing results for tags 'scope creep'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Support
    • Open Forum
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Test / QA
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce
    • Invision Community
  • Jobs
    • Looking for employee / consultant
    • Looking for Job / Assignment
  • Building The Site's Forums
  • Destiny 2's Discussions
  • The Journey's Discussions
  • Cinephilia's Topics
  • Cinephilia's Movie Database
  • Diablo 4's Diablo 4 Topics
  • Shadownessence's Topics
  • sensory hyperreactivity's Topics
  • Wolcen's Wolcen Topics
  • Quality Assurance Heroes's QA Topics
  • Visual Studio Code's Forum
  • Adobe Illustrator's Adobe Illustrator Forum
  • Sketch Guru's's Topics
  • Requirements & test management in Jira's Topics
  • Microsoft Teams's Microsoft Teams Discussions

Calendars

  • Community Calendar
  • Professional Events
  • Management Events
  • Requirement Events
  • Design Events
  • Development Events
  • Test Events
  • Atlassian Events
  • Operations Events
  • E-commerce Events
  • Destiny 2's Events
  • The Journey's Events
  • Cinephilia's premieres
  • Diablo 4's Diablo 4 Events

Categories

  • Jimi's Files
    • Curriculum vitae
    • Presentations
    • Certificates
  • Management
  • Requirements
  • Design
    • Fonts
  • Code
  • Test
  • Operations
  • Atlassian
    • Certificates of Excellence
  • Security
  • Ecommerce
  • Shadownessence's Files

Categories

  • Management
  • Design
  • Requirements
  • Development
  • Test & QA
  • Atlassian

Categories

  • Personal
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-Commerce

Categories

  • System Science Program
  • Graphic Design Program
  • Single Courses
  • Certifications

Categories

  • Management
  • Design
  • Requirements
  • Atlassian

Categories

  • Management
  • Design
  • Requirements
  • Development
  • Test
  • Operations
  • Atlassian
  • Security
  • E-commerce
  • Sales

Categories

  • Personligt
    • Jimis profiler
    • Åsikter
    • Humor
    • Spel
    • Träning
  • Allmänt
    • Internet
    • Program & tjänster
  • Intressant
    • Prylar
  • Professionellt
    • Management
    • Krav
    • Design
    • Webbutveckling
    • Test
    • Atlassian
    • säkerhet
    • Förvaltning
    • Ehandel
    • Wordpress
  • Personligt_

Blogs

There are no results to display.

There are no results to display.

Categories

  • Personal
    • Humor
    • Music
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce
  • Destiny 2's Videos
  • Destiny 2's Streamers
  • The Journey's Videos
  • Cinephilia's Trailers
  • Cinephilia's Full Movies
  • Diablo 4's Diablo 4 Videos
  • Wolcen's Wolcen Videos
  • Visual Studio Code's Videos
  • Adobe Illustrator's Adobe Illustrator Videos
  • Requirements & test management in Jira's Videos
  • Microsoft Teams's Microsoft Teams Videos

Categories

  • Just for fun
  • TV & Movies
    • Lord of the Rings
    • Star Wars
    • Marvel
  • Atlassian

Categories

  • Games
    • White Wolf
    • Drakar & Demoner
    • Mutant
  • Books
    • Management Books
    • Design Books
    • Development Books
  • Comics

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 2 results

  1. Requirements are abused almost daily and it is a fact that most projects that fail miserably do so because the requirement process failed. Lets go over what requirements are and how to make sure you control the requirements and in doing so also control your project. "A requirement is a legal agreement that dictates what has been agreed upon and as such it must be defined in a way that can be verified." That is pretty much the summary of what a requirement is, but it's a bit more complicated than that as a requirement is made up of three different parts: Business need - What people usually think a requirement is. Its a description of a need that should be fulfilled and it can come from the business or the end user perspective. The technical elaboration - The part that is most lacking and the cause for so many failed/costly projects. This takes the business need and extend it with the technical elaborations that make it possible to design or code the solution. The verification aspect - This part is where each part of the requirement is defined in a way that it can be verified with true or false statements. It ensures that the requirement have the right level of clarity. Once you break down the requirement in these three areas you will naturally see the need to involve the correct users in the requirement process. The business need comes from the product owner, who also own the requirement. The technical elaboration comes from the developers and the verification aspects comes from test. Once the concept that a requirement is a trinity and not a simple request or wish, then you will have come a bit closer to how to get great requirements that are easy to work with and to understand, without having to spend endless hours to formalize them. You can focus on making sure each of the three parts get improved and making sure that there is a natural handover between the requirement phase and development where the development team approves the requirement instead of just inherit it. In order for this to work there are some things you should make sure you either stop or start doing. Here is my list of some of these things: Make sure you add business value to your requirements. Requirements cost money and I don't mean when they are being developed. The cost for elaborate on a requirement also cost money so do not waste money on requirements that does not provide a clear value for the product. Make sure you do not forget the "Why" in the user story! The Why often explain why the requirement exist and its what you compare against when deciding if a requirement is valuable enough to warrant the cost to realize it. Make sure you break down user stories to avoid huge requirements. It is easy to end up to high in a requirement, but you need to break it down so it's easy to understand and so it fit within one development period if you are in an agile work process. A requirement is NOT equal to development! There is no 1-1 relation between a requirement and development, just as there is no 1-1 relation between development and test. So unless you will start to write your requirements as a function specification do not expect development to be 1-1 with the user story. Don't refer to other requirements or share user story for multiple development. Each user story is atomic and should be able to survive on it's own completely independent of other user stories. Link to solution designs and things like that, but never to another requirement in order to explain the acceptance criteria. Don't describe solutions. It is up to the developer to decide on the proper technical solution and the requirement should refrain from describing solutions as the technical solution can change based on other development. Never add variables in a requirement by using words like and, or, with, approx. , etc. and so on. Make the requirement clear and free from interpretations. Never use indefinable terms like future proof, faster, user friendly, versatile or robust. Also refrain from using the term responsive as it's also open to interpretation. Don't ramble. Each acceptance criteria should be short and verifiable. If you feel the need to explain the acceptance criteria, then it's probably not properly defined yet. Make sure each acceptance criteria is verifiable. Think of them as check boxes that can be either true or false. If interpretation is needed then the acceptance criteria is not good enough. Make sure that most of the questions from the development team is answered. Instead of repeating the answers over and over, write them down. In order to get this make sure you involve the developers so they can ask the questions right away. Make sure the requirement take the work process in consideration. If you ask for a new component where you want to set a font color for example, then define how you would want to do that. There is a big different between getting a drop list of predefined colors, an input field for hex codes or a color wheel and it will affect your work process. Always let the developers approve the requirement. This ensures that they take over the responsibility and they verify that they understand what you want them to build. Once the development team have taken ownership never alter the requirement by adding or removing functionality. Only clarifications should be done at this stage or there will be mayhem and scope creep. Find the right level! There is no need to go bananas and spend weeks on a requirement unless the organisation need it to get the requirement properly defined. The better each of the three parts of the requirement become at defining the requirement, the faster it will go without loosing quality. You need to find that level where the requirement is optimal for your team. These are just some small notes on what you can do to improve the quality of requirements. I have worked with clients that knew nothing of requirements and did the Agile/Ad Hoc version where they never got a project out in time or on budget. Once properly trained they not only mastered the art of requirements, but they also managed to keep deadlines and budgets. I aim to write a bit more about this topic later on, but perhaps there is a specific topic you would want me to address right away?
  2. Requirements are abused almost daily and it is a fact that most projects that fail miserably do so because the requirement process failed. Lets go over what requirements are and how to make sure you control the requirements and in doing so also control your project. "A requirement is a legal agreement that dictates what has been agreed upon and as such it must be defined in a way that can be verified." That is pretty much the summary of what a requirement is, but it's a bit more complicated than that as a requirement is made up of three different parts: Business need - What people usually think a requirement is. Its a description of a need that should be fulfilled and it can come from the business or the end user perspective. The technical elaboration - The part that is most lacking and the cause for so many failed/costly projects. This takes the business need and extend it with the technical elaborations that make it possible to design or code the solution. The verification aspect - This part is where each part of the requirement is defined in a way that it can be verified with true or false statements. It ensures that the requirement have the right level of clarity. Once you break down the requirement in these three areas you will naturally see the need to involve the correct users in the requirement process. The business need comes from the product owner, who also own the requirement. The technical elaboration comes from the developers and the verification aspects comes from test. Once the concept that a requirement is a trinity and not a simple request or wish, then you will have come a bit closer to how to get great requirements that are easy to work with and to understand, without having to spend endless hours to formalize them. You can focus on making sure each of the three parts get improved and making sure that there is a natural handover between the requirement phase and development where the development team approves the requirement instead of just inherit it. In order for this to work there are some things you should make sure you either stop or start doing. Here is my list of some of these things: Make sure you add business value to your requirements. Requirements cost money and I don't mean when they are being developed. The cost for elaborate on a requirement also cost money so do not waste money on requirements that does not provide a clear value for the product. Make sure you do not forget the "Why" in the user story! The Why often explain why the requirement exist and its what you compare against when deciding if a requirement is valuable enough to warrant the cost to realize it. Make sure you break down user stories to avoid huge requirements. It is easy to end up to high in a requirement, but you need to break it down so it's easy to understand and so it fit within one development period if you are in an agile work process. A requirement is NOT equal to development! There is no 1-1 relation between a requirement and development, just as there is no 1-1 relation between development and test. So unless you will start to write your requirements as a function specification do not expect development to be 1-1 with the user story. Don't refer to other requirements or share user story for multiple development. Each user story is atomic and should be able to survive on it's own completely independent of other user stories. Link to solution designs and things like that, but never to another requirement in order to explain the acceptance criteria. Don't describe solutions. It is up to the developer to decide on the proper technical solution and the requirement should refrain from describing solutions as the technical solution can change based on other development. Never add variables in a requirement by using words like and, or, with, approx. , etc. and so on. Make the requirement clear and free from interpretations. Never use indefinable terms like future proof, faster, user friendly, versatile or robust. Also refrain from using the term responsive as it's also open to interpretation. Don't ramble. Each acceptance criteria should be short and verifiable. If you feel the need to explain the acceptance criteria, then it's probably not properly defined yet. Make sure each acceptance criteria is verifiable. Think of them as check boxes that can be either true or false. If interpretation is needed then the acceptance criteria is not good enough. Make sure that most of the questions from the development team is answered. Instead of repeating the answers over and over, write them down. In order to get this make sure you involve the developers so they can ask the questions right away. Make sure the requirement take the work process in consideration. If you ask for a new component where you want to set a font color for example, then define how you would want to do that. There is a big different between getting a drop list of predefined colors, an input field for hex codes or a color wheel and it will affect your work process. Always let the developers approve the requirement. This ensures that they take over the responsibility and they verify that they understand what you want them to build. Once the development team have taken ownership never alter the requirement by adding or removing functionality. Only clarifications should be done at this stage or there will be mayhem and scope creep. Find the right level! There is no need to go bananas and spend weeks on a requirement unless the organisation need it to get the requirement properly defined. The better each of the three parts of the requirement become at defining the requirement, the faster it will go without loosing quality. You need to find that level where the requirement is optimal for your team. These are just some small notes on what you can do to improve the quality of requirements. I have worked with clients that knew nothing of requirements and did the Agile/Ad Hoc version where they never got a project out in time or on budget. Once properly trained they not only mastered the art of requirements, but they also managed to keep deadlines and budgets. I aim to write a bit more about this topic later on, but perhaps there is a specific topic you would want me to address right away? View full article
×
×
  • Create New...