A Product Backlog is a list of top-level requirements that are usually associated with a single Project or Product.
The Project Management Body of Knowledge (“PMBOK”) describes 12 Principles of Risk Management. I’ve taken the headings and summarised the main messages from an Agile perspective…
Risk identification is the first stage in the Agile Risk Management process. This stage is followed by Risk Assessment, Risk Response and Risk Review.
Risk Assessment is the second stage in the Agile Risk Management process. This stage is preceeded by Risk Identification, and followed by Risk Response and Risk Review.
Risk Response is the third stage in the Agile Risk Management process. This stage is preceeded by Risk Identification and Risk Assessment and followed by Risk Review.
Risk Review is the final stage in the Agile Risk Management process. This stage is preceeded by Risk Identification, Risk Assessment and Risk Response. A Risk is an uncertain event that will impact your chosen path should it be realised. Risks are events that are not currently affecting you – they haven’t happened yet. Once a
Risks are traditionally identified, assessed, responded to and monitored by a Project Manager. In Agile working environments the responsibility for risk management is shared by all involved. There don’t seem to be any official guidelines on how to manage risks within an Agile environment, so I’ll combine my personal views/learning with notes/ideas I’ve found scattered around the web.
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?