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

Recommended Posts

  • 2 weeks later...
  • Replies 1
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By ©Jimi Wikman
      Jira tool manager with the task of stabilizing the system and setting up work processes for all teams within H&M. Responsible for several projects including cloud initiatives and coordination with other systems such as ServiceNow. Heavily involved in designing the build processes (requirements, development, design, deploy and test) for the process office. Responsible for the design and implementation of SAFe in Jira and the build processes. Responsible for a small team of Atlassian experts. Supported 400+ teams with Jira questions and training of work processes.
    • By ©Jimi Wikman
      Requirements are very important. In fact I would say that 95% of all failed IT projects can be traced to a poor requirement process. This is baffling because requirements are really not that complicated and yet I see people fail in organization after organization.
      After I started to look into the different flavors of Requirements I start to understand why things are so very hard to understand for many. There are such confusion about what type of work you should actually do, who you actually work for and what you actually should deliver.
      So let us define what a requirement is first:
       
      "A Requirement is a legal agreement between the requester and the performer."
       
      That statement alone will surely get a few people raising their eyebrow for the simple reason that it does not fit in their job description. Again this baffles me that we have so many different work description for a single discipline. My only explanation is that people are confused on what different levels you work with requirements.
      If we simply break down the three most common way of working I have seen: Facilitate, Investigate and Document. Then add it to the three common areas of work: Business, IT and translation between the two, then we can make a nice matrix. From there we can see what actual roles people have.
       

       
      For me I think that anyone working with facilitating meetings as their primary function is a manager. Anyone who just document the need is a secretary. Those two types of "requirement analysts" I see frequently and in my opinion we should make sure that we call them for what they are so people do not think that this is requirement work.
      In the investigative category it is common to work in all 3 areas depending on who you work for. Business analysts help business to define their need and IT analysts help IT define their need. This is however not requirements as their final product, but need. That comes BEFORE requirements. In this matrix we can see that the only role that actually work with requirements as the final product are the Requirement Analysts. This makes sense since the definition of requirements as a final product is:
       
      "The outcome of a Requirement is a translation between need and realization of that need."
       
      This is where many fail. I see many, many requirements that are nothing more than a granular break down of a need, but lacking the translation.  Many are often either to undefined and border on a business need, or other times I see technical specifications instead of the need. My theory is that people do not understand what requirements are and who they are for.
      We can see this in the delivery of requirements as well. I do not know how many times I have seen people claiming to work with requirements simply dump a bunch of documents on the development team and move on to next project, or next iteration of the project. This way of working when you build walls and throw packages over it is NOT a proper way to work with requirements.
      As we can see in the matrix above a requirement analyst sit between business and IT. There she function as a bridge between the two, translating need in both direction to ensure everyone understand and agree on what should be realized. This can only be done with active communication, person to person, and you never deliver a requirement, you make a handover.
      I think that this is the key for making requirement processes work: handover and asking development and test to take over the responsibility of the requirement. To ask the most important question there is: "do you understand what business want and can you realize that need with the information you have been provided?" If the answer is no to that question, then you are not done with the requirement.
      If you just understand your place in the requirement process and you understand what a requirement is, then the requirement process will be easy for you. If your organization understand that as well, then life will be great for everyone.
       
      So do you still think requirements are difficult?
    • By ©Jimi Wikman
      The requests to get Portfolio for Jira for Cloud users have been loud and finally Atlassian released a Cloud version. They also made a very odd choice to rename Portfolio for Jira to Advanced Roadmaps and place it behind the Cloud Premium barrier.
      Portfolio for Jira has long been the better choice for Jira Server and Jira DC users. The features have been perfectly suited for managers to keep an overview over large programs and initiatives with relative ease. As such it has been the envy of Cloud users for years and it comes as no surprise that Atlassian would port this to Cloud given their focus on the cloud platform lately.
      Renaming Portfolio for Jira is also no surprise as it confuse managers with two portfolio products where the high level Portfolio tool Jira Align is the product Atlassian seem to want to focus on. Renaming it to Advanced Roadmaps is however a very strange choice as it is not a simple roadmap tool. It also make the naming confusion shift from Portfolio to Roadmaps as Cloud users have been using the limited Roadmaps feature for quite some time.
      The new Advanced Roadmaps is only available for Cloud Premium users. This makes sense as Atlassian want to push users into their new price model. Currently there is not much that would warrant double the price for Cloud Premium so Atlassian need something that is enticing enough for users to make the shift. Advanced Roadmaps could be one of those features, but they need more as Advanced Roadmaps cost $2.3/user and month at it's lowest level and Cloud Premium cost an additional $7/user and month.
      Feature wise Advanced Roadmaps is still great with the two main selling points of great overview and the ability to scale the issues with more levels. Here are some of the selling points from Atlassian:
      With the changes coming to Roadmaps where all projects will get them, and not just Next-Gen projects, combined with the promise that Advanced Roadmaps will somehow be connected to a more comprehensive whole this could be a pretty good thing for Cloud Premium users. Adding Advanced Roadmaps to Cloud Premium will now add the ability to scale issue types beyond the standard 3 levels, which is something people have asked for for a very long time.

      Will it be enough to warrant the high price tag for Cloud Premium? I doubt that as Advanced Roadmaps is only really useful when you pass a certain number of teams. Doubling the price tag will probably discourage most low to mid-range clients. The fact that you can only have a 7 day test version and that you need to setup a new cloud instance to even test this if you are on a regular cloud plan is also a problem. With more features added into Cloud Premium however I think more and more will make the shift over to that.
      Overall this is a good new addition and package it with the Cloud Premium offer will make it more accessible and therefore used, which is a good thing. It's a bit sad to see Atlassian being so aggressive in their way of forcing cloud users into their Premium tier that is making some old customers a bit annoyed, but I think it will be good in the long run.
    • By ©Jimi Wikman
      As an Atlassian Platinum Solution Partner Enterprise and a Platinum Top Vendor in the Ecosystem, we’ve been working hard on enhancing the use of Jira Software for over 2500 business teams around the globe. This app adds Requirements, Test Plans, Test Cases and Test Executions panels to your software project in Jira and thus allows you to track the whole development process from collecting requirements to going to production in a single place.   Try the app out for free on the Atlassian Marketplace:    Follow us on other channels:
      https://www.linkedin.com/company/devi... http://twitter.com/deviniti_voice http://facebook.com/DevinitiPL
    • By + Michael Karlsson
      Michael is passionate about test, QA, requirements work and agile a way of working. He is happy to work hands-on as test leader / test coordinator / tester. Michael has worked on developing complex system solutions where quality in business and deliveries are important. In many cases, his work has led to an increased productivity for the test area.
      Michael is a problem solver where his dedication inspire the team. He like to support others and to share his knowledge. He thrives best when he can combine test management with testing and requirements work in close collaboration with customers and developers. Michael speaks and writes freely in Swedish and English and has extensive experience working in international environments.

×
×
  • Create New...