Mine has always been writing user stories. It is when all the ideas take shape and begin their journey to a shiny new product. I know that not everybody feels the same way. I understand why, especially when it comes to writing User Stories for back-end systems, for example, APIs, as these can be particularly challenging.
In our previous blogs, we described the transition to running projects remotely, explained the adjustments we made to keep effective communication with our distributed team and dived deep into practicalities of remote Agile Sprint Planning. We initially thought of dedicating this blog to remote agile stand-ups but in the end, decided to change the focus slightly. At times when 35-40% of adults in the UK have reported concerns about their mental health, and every second person worries about his/her wellbeing, it's crucial to support our employees. So, what exactly can be done? When it comes to staff emotional health, we believe there is no 'fits all' solution; it is a combination of small adjustments that can be weaved into every meeting or team interaction.
According to the 6th principle of the Agile Manifesto: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." So, does it mean that managing agile projects in the new world of large-scale remote working is impossible? Our answer is no! In the previous blog, we talked about how we ensure efficient communication with the home-based teams. In this blog, we discuss the important adjustments we’ve made to our remote Sprint Planning meetings as part of our Agile project delivery.
The quality of communication within a project team is often the most important aspect in the successful delivery of any project. Since our switch to remote working at the start of the pandemic, we’ve been faced with the challenge of using our project management tools in different ways to ensure that the quality of our communication and collaboration doesn’t suffer.
COVID-19 has turned our lives upside down. Just a few weeks ago, companies had to quickly transition all employees to work remotely. As businesses and people are gradually adjusting to the new circumstances and realising the benefits of working from home, many predict that this operation model is here to stay far beyond the crisis.
Successful software delivery is based on careful planning, accurate estimation and a good understanding of what is in and out of scope. In traditional project management, projects are broken into work packages and assigned to specialists for sizing and estimation. These packages are in turn broken up into progressively smaller modules to get increasingly more accurate sizing. After that, all the sizings are rolled up, and a project plan is reviewed and monitored.
Imagine a typical scrum scene - the team gathers around the board for the daily standup, one of the team members gives his/her overview of the matters at hand. Things seem to be going well until somebody mentions a dreaded 'blocker' word. Suddenly the team panics, the ears of the scrum master perk up, and madness ensues.
Not all user stories are equal. Some may be larger and more complicated than others. The challenge in agile delivery is to keep stories at the right size. That way, they are easily understood and delivered. Those that are too large pose a risk. Wherever possible, you should break them down into smaller, more manageable pieces. In this blog, I will explore factors that might lead to user stories being too 'large'?
At Infomentum, we love to share. We do it daily with our clients through close collaboration with their development teams, training sessions, Agile sprints and support calls, etc. Our team members also share by regularly organising charitable events and donation initiatives. On this occasion, we had a chance to give something a little different – share our knowledge and experience of Agile methodology.
As the old saying goes 'calm waters never made a good sailor'. Applying this maritime proverb to a somewhat different, but none the less hazardous field like IT project management, certainly has its merit. The reality of IT project management in the modern age is a tale of delayed project go-lives and project completion beyond the original budget and time frame.
