I think we’re all agreed that an epic is a very large user story, however in my experience, *most* ‘very large’ stories can and should probably be broken down into smaller stories so as to minimise complexity.
With that said, you may choose not to release the individual stories until the full epic is ‘done’ – this is quite common.
Themes can be used at different levels of hierarchy and on multiple levels i.e. you may have themes within themes.
At the highest level, you’d probably want to ensure they’re aligned with your overall business objectives – they may span programmes or projects.
I guess the main point here is a theme is a grouping technique whereas epics and stories are actual deliverables… although a story could never be broken down into an epic.
Hope that makes sense and helps to clarify my thinking.
All issues are indeed realised risks, however not all realised risks are issues.
An issue describes a negative event/situation that has happened or is happening.
A risk describes something positive or negative that *might* happen in the future – a possible event(s), which deviates from our expected outcome.
Truth is we don’t usually track positive risks in the same way as those which may disrupt our ideal path… we just pray/look forward/try our best to realise them!
Unfortunately it’s not a scalable template. To create a 20 day sprint backlog template you’d need to update all of the burndowns etc. I’ll see if I can find some time over the next couple of weeks to make a 20 day sprint template for you!
Subscribe to my RSS feed if you haven’t already so that you will be notified once it’s up.
The number of story points that a team can complete (on average) in one sprint is known as their ‘velocity’.
Before you start estimating stories, make sure that everyone agrees on what a 1 point, 3, point, 5 point (etc) story ‘looks’ like. Some teams will bring these examples along to their planning poker workshops as a reminder until they get used to their scale.
So, for example, all 3 point user stories should on average take the same amount of effort to deliver. With that in mind, assuming each sprint has the same amount of effort available (same number of people in the office, with the same skillset (ideally the same people!), for the same number of days) then the same number of points will generally be delivered in the pre-agreed number of days.
It usually takes a few sprints before a team can get a sense of their true velocity. This velocity then acts as a starting point for negotiation – more or fewer points may actually be committed to depending on other influencing factors (e.g. team members on holiday etc.)
In this instance, the ten categories drive the ten category-level burndown charts – hence why they’re limited to ten (although we rarely use more than 4 in a particular sprint).
I actually use the ‘category’ field to differentiate between products and/or product owners. I could also imagine using them to track progress against objectives.
Feel free to insert additional columns if you would like to add another level(s) of hierarchy e.g epic, project, theme etc… – we do.
They’re blatantly talking about 5% of people having more than 100 followers… I guess they could have said 5%… but then we’d have no picture to blog and/or comment about. lol
I vote you point out the fundamental flaw in their diagram and let us know what they come back with…
It’s interesting you see it that way. I rather like the abstract nature of Story Points.
When we were estimating in hours, our Stakeholders/Product Owners/Senior Management often over-analysed the situation – the fact we were using a more precise measurement lead them to believe that we were being accurate!
The reality of the situation is we never actually booked a sprint at 100% capacity. In fact, I remember one occasion where a team of four entered into a two week sprint with 60 hours of work. This raised all sorts of questions…
e.g.
“why did Bob only work 20 hours last sprint?”
“but they’ve only committed to a fraction of their capacity?!”
“that team’s not working hard enough”
Announcement: It seems the Google Translation Engine has temporarily banned us from using their service! …..We’ve made too many calls in too short a timeframe…Come on Google ;o)
If you – I’ll let you know when it’s all back up and working.
I Agree! In fact, I just replaced the Youtube URL with the link to that video within the Agile101 video section, where I’ve summarised a few of the key discussion points.
For those of you interested in watching other videos about Agile Retrospectives, check out the video section – https://agile101.net/category/video/.
That’s a tough one – it varies. In one area we’ve got a 1:1 PM:PO ratio, in our largest portfolio team we’re looking at more of a 1:10 PM:PO ratio. In the latter example, we rely heavily on the Primary Product Owner for guidance re: portfolio/programme-level priorities e.g. Themes/Epics, however still look to the POs for guidance at an Epic/Story level.
As mentioned in the overview, there are quite a number of responsibilities I’ve listed above that could be carried out by a Product Owner, Product Manager or both. I suppose each situation/company is different.
In my company, the Product Owners and Product Managers work together (to varying degrees depending on circumstance) to define strategy, requirements and priorities – it’s a collaborative process. In most situations, the PM will be fluent enough to communicate requirements on behalf of the PO however there are definitely times when we ask the PO to join us for a Requirements Workshop or Sprint Planning Session.
It is sometimes not feasible for all Product Owners to join our planning sessions – one team has over 40 POs! In this situation either the PM will be empowered to represent the POs or a Primary PO will attend i.e. the Managing Director.
With that said, because of the number of products in our portfolio (+/- 100), it would be impossible for the PMs to give each product the attention and consideration it deserves (particularly if they’re low(er) on the list of *current* priorities) – the Product Owners keep track of this and highlight changes in priority across the portfolio.
In short – there’s no simple answer. What a cop-out!
I’m actually in the process of writing a post about the Agile Estimation Workflow. Go ahead and subscribe to my RSS feed to be notified when I post it. I’m hoping to do it this week and I’ll be sure to answer your questions – Keep them coming!
I’m not sure I agree that it is essential (or viable in a lot of cases) to have a customer involved in sprint planning. That is if by ‘customer’ you mean the end user of the product e.g. a visitor to a website if your website is your product.
The only people required to attend a sprint planning meeting are the Product Manager, a Product Owner(s) if possible/appropriate (e.g. you’re discussing multiple products within the session and the Product Manager is less familiar with certain aspects) and the Scrum Team. In some situations, the Product Manager may even leave after presenting the backlog and agreeing the Sprint Objectives – at this point it’s up to the Scrum Team to figure out the specifics of their Sprint delivery strategy.
I’ve written a blog post about how to run a Sprint Planning session - check it out and let me know if you do things differently.
The Difference Between Agile Themes, Epics and User Stories
April 4th, 2011 at 4:09 pmHi All,
I think we’re all agreed that an epic is a very large user story, however in my experience, *most* ‘very large’ stories can and should probably be broken down into smaller stories so as to minimise complexity.
With that said, you may choose not to release the individual stories until the full epic is ‘done’ – this is quite common.
Themes can be used at different levels of hierarchy and on multiple levels i.e. you may have themes within themes.
At the highest level, you’d probably want to ensure they’re aligned with your overall business objectives – they may span programmes or projects.
I guess the main point here is a theme is a grouping technique whereas epics and stories are actual deliverables… although a story could never be broken down into an epic.
Hope that makes sense and helps to clarify my thinking.
Tara
Agile Risk Management - The difference between Risks and Issues
July 14th, 2010 at 7:16 pmHi Roberto/Taylor,
All issues are indeed realised risks, however not all realised risks are issues.
An issue describes a negative event/situation that has happened or is happening.
A risk describes something positive or negative that *might* happen in the future – a possible event(s), which deviates from our expected outcome.
Truth is we don’t usually track positive risks in the same way as those which may disrupt our ideal path… we just pray/look forward/try our best to realise them!
Tara
Sprint Backlog Template with Objective-Level Burndowns
December 9th, 2009 at 8:42 pmHi Mark,
Unfortunately it’s not a scalable template. To create a 20 day sprint backlog template you’d need to update all of the burndowns etc. I’ll see if I can find some time over the next couple of weeks to make a 20 day sprint template for you!
Subscribe to my RSS feed if you haven’t already so that you will be notified once it’s up.
Thanks,
Tara
Value Points - Estimating the relative value of a User Story
December 9th, 2009 at 12:48 pmHi Raj,
The number of story points that a team can complete (on average) in one sprint is known as their ‘velocity’.
Before you start estimating stories, make sure that everyone agrees on what a 1 point, 3, point, 5 point (etc) story ‘looks’ like. Some teams will bring these examples along to their planning poker workshops as a reminder until they get used to their scale.
So, for example, all 3 point user stories should on average take the same amount of effort to deliver. With that in mind, assuming each sprint has the same amount of effort available (same number of people in the office, with the same skillset (ideally the same people!), for the same number of days) then the same number of points will generally be delivered in the pre-agreed number of days.
It usually takes a few sprints before a team can get a sense of their true velocity. This velocity then acts as a starting point for negotiation – more or fewer points may actually be committed to depending on other influencing factors (e.g. team members on holiday etc.)
Make sense?
Tara
Sprint Backlog Template with Objective-Level Burndowns
November 2nd, 2009 at 9:49 amHi Ed,
In this instance, the ten categories drive the ten category-level burndown charts – hence why they’re limited to ten (although we rarely use more than 4 in a particular sprint).
I actually use the ‘category’ field to differentiate between products and/or product owners. I could also imagine using them to track progress against objectives.
Feel free to insert additional columns if you would like to add another level(s) of hierarchy e.g epic, project, theme etc… – we do.
Thanks,
Tara
The Difference Between Waterfall, Iterative Waterfall, Scrum and Lean Software Development (In Pictures!)
October 28th, 2009 at 4:30 pmHi Reow,
I’m not sure I follow your comment. Lean is anything but an ‘epic fail’…
/
Could you elaborate?
Thanks,
Tara
Sprint Planning: Hours or Story Points (?) - that is the question!
October 5th, 2009 at 12:40 pmActually, I was referring to Black Team when I wrote that.
I stand corrected – TWO of our teams used to create task cards with the words ‘just do it’ written on them! :p
If Twitter was 100 people - Twitter Demographics and Usage Trends
September 9th, 2009 at 9:42 pmHow funny!
They’re blatantly talking about 5% of people having more than 100 followers… I guess they could have said 5%… but then we’d have no picture to blog and/or comment about. lol
I vote you point out the fundamental flaw in their diagram and let us know what they come back with…
Measuring Programmer Productivity - A scientific study
September 3rd, 2009 at 11:17 amComment by: Shah Manish (As posted on Dzone)
your study information is really very good i like it we also good services provide face recognition system biometric fnger print reader etc.
http://www.aditechjustlook.com
http://www.aditechinfotech.com
Scrum Product Backlog Template (with Priority Overview)
September 2nd, 2009 at 3:13 pmWell spotted! Fixed.
Sprint Planning: Hours or Story Points (?) - that is the question!
August 24th, 2009 at 11:21 pmHi Dennis,
It’s interesting you see it that way. I rather like the abstract nature of Story Points.
When we were estimating in hours, our Stakeholders/Product Owners/Senior Management often over-analysed the situation – the fact we were using a more precise measurement lead them to believe that we were being accurate!
The reality of the situation is we never actually booked a sprint at 100% capacity. In fact, I remember one occasion where a team of four entered into a two week sprint with 60 hours of work. This raised all sorts of questions…
e.g.
“why did Bob only work 20 hours last sprint?”
“but they’ve only committed to a fraction of their capacity?!”
“that team’s not working hard enough”
We no longer have these types of conversations.
Just a thought.
Tara
Agile101 Goes International!
August 24th, 2009 at 7:30 amHi Bale,
Fair point. Let’s see how it gets on over the next few weeks – I’ll make sure not to be too disappointed if the non-english versions are unsuccessful
Perhaps we should re-name this ‘Agile101 International (Beta)’? lol
Tara
Agile101 Goes International!
August 22nd, 2009 at 11:37 pmAnnouncement: It seems the Google Translation Engine has temporarily banned us from using their service! …..We’ve made too many calls in too short a timeframe…Come on Google ;o)
If you – I’ll let you know when it’s all back up and working.
Tara
Doing Agile is a Sign of Incompetence
August 22nd, 2009 at 12:21 pmI Agree! In fact, I just replaced the Youtube URL with the link to that video within the Agile101 video section, where I’ve summarised a few of the key discussion points.
For those of you interested in watching other videos about Agile Retrospectives, check out the video section – https://agile101.net/category/video/.
Tara
Value Points - Estimating the relative value of a User Story
August 22nd, 2009 at 9:40 amHi All,
I’ve just finished writing about Agile Estimation and the Cone of Uncertainty – this answers most of the questions above.
Tara
The Product Manager - Role and Responsibilities
August 17th, 2009 at 2:36 pmThat’s a tough one – it varies. In one area we’ve got a 1:1 PM:PO ratio, in our largest portfolio team we’re looking at more of a 1:10 PM:PO ratio. In the latter example, we rely heavily on the Primary Product Owner for guidance re: portfolio/programme-level priorities e.g. Themes/Epics, however still look to the POs for guidance at an Epic/Story level.
The Product Manager - Role and Responsibilities
August 16th, 2009 at 12:24 pmThat’s a really good question.
As mentioned in the overview, there are quite a number of responsibilities I’ve listed above that could be carried out by a Product Owner, Product Manager or both. I suppose each situation/company is different.
In my company, the Product Owners and Product Managers work together (to varying degrees depending on circumstance) to define strategy, requirements and priorities – it’s a collaborative process. In most situations, the PM will be fluent enough to communicate requirements on behalf of the PO however there are definitely times when we ask the PO to join us for a Requirements Workshop or Sprint Planning Session.
It is sometimes not feasible for all Product Owners to join our planning sessions – one team has over 40 POs! In this situation either the PM will be empowered to represent the POs or a Primary PO will attend i.e. the Managing Director.
With that said, because of the number of products in our portfolio (+/- 100), it would be impossible for the PMs to give each product the attention and consideration it deserves (particularly if they’re low(er) on the list of *current* priorities) – the Product Owners keep track of this and highlight changes in priority across the portfolio.
In short – there’s no simple answer. What a cop-out!
Thoughts, everyone?
Value Points - Estimating the relative value of a User Story
August 13th, 2009 at 8:23 amHi Sam,
Great questions!
I’m actually in the process of writing a post about the Agile Estimation Workflow. Go ahead and subscribe to my RSS feed to be notified when I post it. I’m hoping to do it this week and I’ll be sure to answer your questions – Keep them coming!
Thanks,
Tara
Prioritising for Profit - Creating and Prioritising Product Backlogs
August 10th, 2009 at 9:31 amHi Wilco – In the UK it’s prioritiSing, so you’ll have to bear with me.
Tara
How Agile Are You? (The Survey!)
August 6th, 2009 at 12:33 pmHi Dan – You’re welcome!
I’m not sure I agree that it is essential (or viable in a lot of cases) to have a customer involved in sprint planning. That is if by ‘customer’ you mean the end user of the product e.g. a visitor to a website if your website is your product.
The only people required to attend a sprint planning meeting are the Product Manager, a Product Owner(s) if possible/appropriate (e.g. you’re discussing multiple products within the session and the Product Manager is less familiar with certain aspects) and the Scrum Team. In some situations, the Product Manager may even leave after presenting the backlog and agreeing the Sprint Objectives – at this point it’s up to the Scrum Team to figure out the specifics of their Sprint delivery strategy.
I’ve written a blog post about how to run a Sprint Planning session - check it out and let me know if you do things differently.
Hope that makes sense,
Tara