Views
1 year ago

moveIT 2 powered by Goyello – The Cloud Issue

The second issue of moveIT provides experts’ insights on the benefits and threats related to the cloud, success stories of delivered cloud-based projects and interviews with industry gurus. Goyello is an international IT strategy consulting and software development company. We deliver what we promise: innovative, top quality solutions, on time and within budget. Goyello - Quality Software Solutions - Delivered With Care - https://goyello.com/.

TREN MICHAŁ WARKOCZ

TREN MICHAŁ WARKOCZ Scrum Master, Agile Coach CURR IT 5 MYTHS OF SCRUM PLANNING DEBUNKED Every day, as a Scrum Master and Agile Coach, I deal with issues that result from a lack of understanding of the basic rules of Scrum. For the sake of both clients and team members, it’s worth dispelling some of the most common myths of Scrum planning and estimating. 1. Estimate equals commitment Project Managers who have no experience with Agile software, but do have a background in waterfall methodologies, tend to confuse estimate and commitment so let me define the difference between those two. An Agile estimate tells you how much the team hopes it will take them to get the job done. The Sprint Goal defines the team’s commitment. It tells you what the team promises to deliver during an upcoming Sprint as an Increment. 2. A Sprint Goal is optional A Sprint Goal is essential to the success of the Sprint. There are several reasons for this. Firstly, it is the team’s commitment and, secondly, it defines whether the Sprint was a success. Thirdly, and most importantly, the Sprint Goal is the Guiding Thought for the team, especially if things do not go as expected. 3. You cannot modify the Sprint Backlog after Scrum Planning The Sprint Backlog is a plan of how the team wants to reach the Sprint Goal. As new things are learned about the project, the product, and the requirements, the plan will need to be changed and adjusted to meet the Sprint Goal. Changes in the Sprint Backlog can be made by the team, and only by the team, to keep to the plan. 4. You can predict all tasks for the Sprint during Planning Meetings The ultimate law in all software projects is that there will be changes. The team and the Product Owner can’t predict all possible options prior to or during the Sprint Planning. This emergence occurs as the team works through the plan and learns more about the work needed to achieve the Sprint Goal. 5. Work is assigned in Sprint Planning Adapting to change is the essence of Scrum and Agile. If every team member has all the tasks assigned during the Sprint Planning, they are not able to respond to changes. If unexpected tasks come up during the Sprint or someone is underperforming, the workload cannot be flexibly distributed among other members of the team, and the Sprint Goal will not be achieved. 22 MOVE IT IT

ENT MIŁOSZ MUSIALIK Business Analyst DS MAP YOUR IDEAS - STORY MAPPING One of the major factors determining the success of software development is communicating the business value of requirements at every possible stage of implementation. This can be difficult to achieve if the team is only using the flat list of user stories prepared by the product owner’s business analyst. What is more, working with a backlog of hundreds of user stories makes it difficult to maintain an efficient and effective trace of changing requirements. For the business analyst, or any team member whose responsibility is to keep the backlog consistent and ‘just-right’, this has always been a real struggle. To overcome these problems, Jeff Patton introduced a technique called Story Mapping, which has become the leading approach towards requirements management in Agile software development. The User Story Map is the new approach towards backlog creation. In principle, the story map shows the user’s journey and describes it in the form of user stories. It helps the client and the development team see directly what the system does and what its core functionalities are, making the communication more effective and virtually on-demand, even if the product owner is not always available to the team. At Goyello, we have been successfully using story mapping for a variety of projects. From my own experience I can say that the biggest advantage of this method is that it makes the development team focus on the big picture of the solution. The whole map of the system, hung on the wall in the office space, is available any time it is needed. It is much easier to change requirements, only requiring new post-it notes added to the wall. The priorities are no longer just symbols on a list, and you can check them all at a glance. The client can easily create a roadmap for their product just by cutting the map into slices representing the upcoming releases. Sprint planning is no longer a problem: the scope can be determined based on the story map. There are other benefits of using story mapping in software development, however, the simple idea of making the product better is a major factor that encourages our clients and development teams to make use of it. #moveITgoyello

Magazine ‘move IT’ – Powered by Goyello