In a recent post Karl Scotland drew my attention to this post by Craig Dickson on Agile DZone. Karl and Craig differ on their approach (when working with Scrum) to prioritisation of stories by the product owner within a sprint.
Craig has a valid concern that we might loose sight of our Sprint commitment if we have high and low priorities within the sprint, what if we don’t get to low priority stuff, well it was only low priority! He also raises concern over the degree to which the team is empowered if the Product Owner specifies a priority order for within the sprint.
By contrast Karl has his focus firmly on WiP (work in process), and through that lens the sprint is secondary to a focus on flow, prioritisation will encourage the team to focus on flow. I have some sympathy with this point of view.
As is so often the case I feel that I fall between these two camps.
- I believe in an empowered team who pull from the backlog
- I believe in the team making a commitment to a sprint scope
- I believe in the team self-organising around moving that scope through to releasable product
But, there is always a but, these things don’t preclude prioritisation.
We pull from the backlog in order to take into account team capacity / capability. We pull in the correct amount of work with an appropriate profile e.g. not all database heavy wok if we have limited DBA capability. This means that the team may not always pull items from the very top of the backlog. The team commitment is an open honest expectation that this work can and will be achieved by the end of the sprint. We don’t sack or punish the team if a commitment is missed, in fact it could be argued that the commitment should be missed from time to time due to special causes. We don’t want to pad sprint plans with high amounts of contingency. Finally the team self-organise around achieving the goal.
When I introduce teams to Scrum I recommend working against a prioritised sprint backlog. Why? The prioritisation helps in a number of ways:
- The team is challenged to find ways to move stories to Done faster
- The team is encouraged to collaborate and help each other out in favour of picking new tasks
- We bind people to tasks late, prioritisation helps them select tasks according to team need rather than specialisation
- Where a sprint commitment is missed we loose 1 story rather than a bit from each story.
So in short, I agree with much of what Craig has said, it should not be the responsibility of the PO to prioritise the sprint backlog. However, I do see the need for the team and PO to collaborate in order to ensure that the needs of the business do not take second place to the needs of the process. I also share much of Karl’s motivation with respect to limiting WiP and achieving Flow.
For me prioritisation is a strategy that a team can use to self organise around a given sprint commitment. It encourages collaboration and mitigates risk, how can that be bad?
February 3rd, 2010 in
SCRUM | tags:
Prioritisation,
SCRUM,
WIP |
1 Comment
For the majority of agile teams user stories are the preferred tool for requirements management. User stories provide numerous benefits including; a focus on the business problem being solved, a just in time approach to specification, amenability to splitting that supports working in short time-boxes.
The problem with user stories in practice is that the desire to work in short cycles drives teams to split stories to a degree that they can loose sight of the value element from the perspective of a customer or product owner. This is often alleviated through themes or story hierarchies but maybe there is a better way.
The minimum marketable feature (MMF) provides a connection between the high level vision of the project and the detailed user story.
According to Software by Numbers a Minimal Marketable Feature is:
… a chunk of functionality that delivers a subset of the customers requirements and that is capable of returning value to the customer when released as an independent entity.
I have found that this construct offers a powerful approach to assessing, understanding and prioritising feature sets. I believe that the benefits of considering MMFs applies to both software projects and product development activities. Due to the focus that is placed on the need rather than the solution this technique continues to apply where we consider projects with little bespoke software.
In essence given some form of need we must pursue it’s decomposition repeating the challenge; “is the described feature or feature set really so minimal as to be un-deployable should any aspect be missing”. We gain further benefit by asking; “is there any aspect of this specification that is over specified”.
I guess at this stage an example is called for. Imagine for a moment that I am a traditional retailer considering gaining a web presence. I have a vision to develop an online presence in order to increase revenue by attracting a wider customer base.
I can begin assessing my need and decomposing features while ensuring that the resultant chunk remains marketable.
MMF 0
Help prospective customers find out about the business through basic online presence.
MMF 1
Enable online purchasing of restricted set of products
Offer a single form of payment
MMF 2
Broaden product range
MMF 3
Increase payment options
MMF 4
Make special time limited offers
MMF 5
Provide vouchers to encourage repeat custom
I am still experimenting with this approach, however, it seems that as a product increases in maturity MMFs can reduce in size (probably to the point where stories would be adequate). It is early in the process where we can get the most value.
In my experience release planning is an area of weakness for many organisations. Releases are large for a variety of reasons including funding, deployment effort and fear of not getting what you really want. I believe that an aspect of this is that once assigned a project it’s team want it to live on independent of the rest of the organisations portfolio. Applying an MMF approach should ease the job of portfolio management since MMFs have a very tangible value proposition.
July 21st, 2009 in
Agile | tags:
MMF,
Prioritisation |
No Comments
