A Risk is an uncertain event that could impact your chosen path should it be realised. Risks are events that are not currently affecting you – they haven’t happened yet. Once a risk is realised, it has the potential to become an Issue.
Scrum is great at handling immediate issues or in this case, they’re more commonly referred to as ‘Impediments’…
I introduced the Epic Board as a programme management tool – a tangible release plan that can help you to plan software development programmes comprising multiple separate projects combined with Business As Usual Activities.
So, you’ve heard about Agile and Scrum, your company is sold into the benefits, you’ve had your Scrum Master training, you’re good to go… and now you need to set up all of the meetings! This post will give you a simple overview of the Scrum Meetings and some suggestions for how you might like to schedule/run them.
Sprint planning should take place on the first day of the sprint. This session is divided into two parts, the first part is attended by the delivery team and the product manager, whereas the second part is usually only attended by the delivery team.
One of the many benefits of developing software in an iterative way is that you can start realising the benefit of your work before the project is officially ‘finished’.
Value Points can be used to measure the relative value of stories using a Fibonnaci Sequence. Although not appropriate or particularly necessary in all cases e.g. primarily when you have an omni-present Product Manager, these can be a useful way to prioritise and convey relative importance to a team. This approach becomes increasingly useful as teams scale to cover multiple projects combined with Business As Usual activities.
Quality is one of the four performance measures that you should consider when building an Agile Balanced Scorecard. The other three are Value, Velocity and Reliability.
Reliability is one of the four performance measures that you should consider when building an Agile Balanced Scorecard. The other three are Value, Velocity and Quality.
Velocity does by definition assume a degree of quality output by any Agile Software Development Team, by the virtue of the fact that you should only count accepted Story Points towards your velocity.
With that said, there are many other factors that need to be considered when assessing the overall effectiveness of the team.
Although you can not use Velocity to measure the productivity of one team compared to another, you can use velocity to help track the relative productivity of the same team from one sprint to another assuming the value of a point stays the same over time.
We often confuse ‘accurate’ (mean difference) with ‘precise (variance)’. It would be accurate to say that I was less than six foot tall, it would be precise to say that I was…
So, it’s no secret that one of the big benefits of ‘going agile’ is the ability/opportunity to track and optimise team performance.
The big question from a programme management and business perspective is:
How do you measure the operational costs/savings associated with improved efficiency or increased disruption within an Agile Software Development team?
There are numerous benefits to adopting Agile ideals and introducing Scrum/Kanban-esque practices at a programme level. One of these benefits is increased flexibility, which in turn offers improved output, reduced time-to-market and increased value.
So, the following questions are justified:
* What is Agile Programme Management?
* What is Agile Portfolio Management?
* Is it possible to efficiently and effectively manage a Programme of Software Development Projects in an Agile way?
I just heard about this great new product from Idea Paint – it’s paint that can turn all of your walls into whiteboards(!) This is clearly an excitingly geeky prospect for any Agile team.
One of the biggest challenges we’ve faced is trying to balance project work or product development with business-as-usual (BAU) work that can’t necessarily be anticipated – how do you manage the risk of disruption?
The more I use the Epic Board, the more I love it.
Make no mistake about it, I don’t think this tool should (or could) replace a Scrum Task Board – it’s totally different…
Velocity is a measure of how much work a team can complete in a set period of time. It is measured in Story Points and although it was originally created for use in Software Development scenarios, it can be used in just about every type of team scenario. Velocity can be measured assuming you have… : 1 team
I often get asked how an existing team would go about determining their Velocity (the average amount of work a team can complete in a set period of time), so I thought I’d write a post about how we’ve done it in the past…