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.
'There is nothing more powerful in any organisation than having all employees rowing fiercely in the same direction', wrote Brent Gleeson, the founder of Taking Point Leadership. The same can be also applied to teams within any organisation. Long meetings, endless back and forth emails, misunderstandings, and interruptions for impromptu catch ups are symptoms of an inefficient internal department.
The goal of the Head of Operations, was to create a working environment that nurtures collaboration and confidence, allowing efficient and effective delivery and continuous improvement.
In my last article, The evolution of test documentation; lessons learned from implementing Cucumber, I explained two things. Firstly, how we at Infomentum have adopted Behaviour-Driven Development to define test scenarios, and secondly, how we use Cucumber JVM as an implementation platform for running these scenarios as automated tests.
I’ve wanted to write something about Infomentum's scrum board since its inception in late 2012. Now seemed as good a time as any to share the story...
During an end of sprint retrospective, one of our developers Jakub said “I'm bored of the board.” That didn’t surprise me.