So, some of you may know that i'm now a part of what some call a "Top Down" scrum. This means that someone in the development organization or the business organization heard the word scrum or agile and said "Man, we should be doing that" then they told someone below them, and that person told the person below them, and eventually a developer was told "Be more agile".
Well, first, you need a prioritized list of work for the product. No not 3 lists and not a 50 page requirements document. One single prioritized list of high level things that you want the product to do.
This is hard.
As an organization that comes from waterfall, we seem to be accustomed to having a business analyst talk to the product manager who talks to users, stakholders, etc and comes up with a vision for the product. This business analyst talks to them about use cases and test cases and creates elaborate diagrams and screenshots and every gizmo and gadget that could possibly be thought of. ALL of it must be captured before passing on that document over to the developers to start working.
So we just take that requirements document and that is our product backlog right?
(makes buzzer sound) NO... why?
This is ridiculous james, why wouldn't i create my 50 page requirements document for these 8 feature functionalities for this planned release that we want to do.
well, for one, by the time you actually finish that document the opportunity for a market share may already be gone. poof, you just missed out!
for two, your one single business analyst becomes your one single chokepoint of functionality! yikes!
Well, what can we do?
Scrum says, get a product owner. Make it your product manager person, they're already doing half the work (or more) of what a product owner should be doing. (talkin to stakeholders, customers, users, friends, their cat about how the software SHOULD be).
well, where do i put this business analyst then?
Put them in the team, with the developers!
this goes back to my diagram
there's a list of high level ideas, that's the product backlog. All detail is created Just in Time and just enough to get started. Everything else is waste!
let me just be very very very specific.
here's my product backlog:
- customers can login to their account
- customers can edit their login info once logged in
- customers can create a new account
- customers can browse items for sale
- customers can purchase an item
- customers can add an item to their cart for purchasing later
- customers can print an old invoice
Anyhow, let's say our planned release is items 1-4. If we have a BA go off and detail items 1-4, it's going to take them probably 3, 4, 5, maybe 7 weeks... meanwhile the developers are doing god knows what while customers are going to some other company for their business. UNACCEPTABLE!
Step 1, get the above list.
Step 2, take the first item and sit with your developers, and break everything down into very low level "Deliverable" tasks. ... ie
- test cases
- login page UI layout
- login page UI logic
- login logic object
- accounts table
- accounts mock data
step 3, estimate all of these tasks as a group.
step 4, team members choose the tasks they are going to do (business analyst, tech writer, qa person, everyone)
step 5, go do those tasks, when something outside the team keeps you from doing a tasks, inform the team of an impediment (the whole team! including your product owner), every day have a scrum meeting(or standup) and make sure EVERYONE on the team says what they did, what they will do, and what is in their way. Keep in mind, those things they are doing should match the sprint backlog. Scrum master watch for this. -This part is hard-
step 6, demo your potentially shippable products (anything that is "Done"). The rest of it put back on the product backlog for next sprint.
Step 7, have a retrospective, talk about what you did well, what you didn't do well. Make actionable items - Put them on the product backlog. Make sure the WHOLE team is there. -Again, this is hard-
repeat steps 1-7 with a rythmic and concise timing over and over.
of course, there is no cookbook for scrum... this is just how i hope to see it happening :)