If you wonder what a Scrum Product Owner need to do, here’s the checklist (in form of a mind map) for you!
Tag Archives: product-owner
Guest blog by Ellen Gottesdiener: It’s the Goal, Not the Role:The Value of Business Analysis in Scrum
2013-07-09 Ellen Gottesdiener
Ellen Gottesdiener is an internationally recognized leader in the collaborative space where agile requirements + product + project management converge. She coaches, trains, and presents to thousands of people globally and has facilitated hundreds of discovery and planning workshops across diverse industries.
She will hold her popular workshop in Stockholm 25-27 September 2013.
It’s the Goal, Not the Role:The Value of Business Analysis in Scrum
In agile development, what happens to the traditional business analyst? Consider Scrum, currently the most popular agile method. In Scrum, there is no “business analyst” role. In fact, there is not an explicit role for tester, project manager, architect, developer, data administrator, user experience designer, customer support representative, or product trainer. Instead, Scrum has three roles: the product owner, the Scrum Master, and the delivery team. Their collective goal is to deliver high‐valued product needs continually. So, where and how can a business analyst contribute?
Establishing the first common product backlog
2011-11-28 Anders LaestadiusThe past few days at my current coaching assignment have been great. We created a new backlog for all work they need to accomplish in the months ahead. The meetings where we laid the foundation for the future were marked by a high degree of collaboration between the participants and energy. It has been really fun to work with them so far.
Product Owner’s Product and Project Board
2011-10-04 Per LundholmThe team has its Scrum board as an information radiator. It is an excellent way of getting an overview of the sprint. But what about us, the product owners, don’t we need that too? Of course we do, we too have a need for an overview of our work and to radiate information. The stakeholders pass by and ask “what’s in next sprint”, “when will we migrate”. We’d like to just answer with a light gesture towards the wall. It is all there for everyone to see.
Let me tell you how our project owner board works, as an example. read more
Becoming a Product Owner, Part 2
2011-06-12 Per LundholmHere is part 2, a week has past. I think as I write so it is a bit different in style and content than my other posts here.
It has been a hectic week, this first week as PO/SM. First of all, it was only four days thanks to national day. Then there were two new developers from Russia which meant twice as many developers as we had before, not counting me. Simple, you just tell people to pair program. That works out if they are well enough to come to work. Which they weren’t. So they russians were left a bit hanging. I had a lot to do just to keep the team running, at least according to my standards.
Becoming a Product Owner, Part 1
2011-06-02 Per LundholmI am programmer and Scrum Master but has been offered to become Product Owner for the same part of the product I am currently working on. I decided to accept the offer and this is my live story, written as I go. Perhaps this will be of interest to you.
First of all, to me, this was not a decision I took lighthearted. However, I do have the fortune of peer coaching at Crisp and the offer came the same morning we had our last coaching. That was a timing like there was a meaning behind.
It is not supposed to be full-time either, so I need to choose what I shall do the rest of my day. It turned out that initially there was no choice. It was not possibly to find a Scrum Master to fill in my gap. The next sprint I will be both PO and SM. Hua! read more
Where to store the product backlog and the release plan
2011-05-31 Jan GrapeIn my present team we have tried many formats for the product backlog and the best one so far is – PowerPoint!
We started out with Excel. Excel documents are nice because they are easy to distribute and almost everybody has the ability to read and edit them. You can sort the backlog by rearranging lines with cut and paste, but it’s a bit complicated. If you’re not careful you may lose lines/stories. Another drawback is that the the product backlog easily becomes really large. A 200 lines Excel document is a small one, but a product backlog with 200 user stories is huge, especially considering that we do about 15 stories per sprint.
Next we tried out Trac. Trac is a ticket system much like Jira. We liked the idea of having the product backlog in the ticket system where user stories/tickets never get lost, are versioned, accessible via a web interface and can have attachments.
Unfortunately it’s a pain to prioritize in a ticket system if you want an absolute priority order and not just categories like High, Medium, Low etc. You have to add a numeric filed with a priority number and sort the list according to that. Sooner or later you will end up having to manually renumber several stories just to be able to squeeze in some new stories between existing ones.
By now you probably understand that rearranging and prioritizing the product backlog is really important in our team. Our stake holders work very close to the market changing the priorities of upcoming user stories as market windows open and close.
It was with some excitement we tried out ScrumWorks. In ScrumWorks you can rearrange the product backlog using drag and drop. There is a fat client and a web interface and it doesn’t cost any money to get started. We tried the basic and the pro versions. However, there was no success for us. Perhaps it was the need for a fat client to be installed (and in this organization people usually are not permitted to install software on their own machines) or that people needed to learn a new application (Excel and Trac were already known and in use). As it turned out nobody used the application, for whatever reason.
So far, none of the applications we tried out had a natural limit for the number of user stories you pour into the product backlog, which in all cases lead to a very large backlog. That’s a bad thing since it’s only waste to have items in the backlog that won’t be implemented for the next two years, especially in a fast moving business. Unfortunately we didn’t quite have the discipline to keep the backlog small, so we needed something that would help us in this area as well.
Finally, our business analyst Magnus Almkvist came up with the idea to use PowerPoint – one slide per user story. At first it sounded strange, but it actually works really well.
A PowerPoint slide reminds a lot of the original index card that you read an learn about on all Scrum and PO courses. Whatever you write has to fit on a limited space and it’s easy to rearrange the order in the backlog in the slide sorter view in PowerPoint using drag & drop. Color is used to mark user stories that belong to the same epic/theme and different layouts (backdrop/font color) are used to indicate the readiness of a user story (approved, implemented).
The printouts (6 slides per page) are posted on a wall in the corridor where everybody that works with our team can see them. The wall is updated at least once per week, but the original PowerPoint file is stored in Subversion on the intranet and is available for reading to anyone who want the electronic version. We also have a link from our wiki to make the backlog really easy to find.
In our backlog grooming sessions (once or twice per week) where out PO team meets with the stake holders to prioritize, add to and remove from the product backlog, the printouts are put on a big conference table (no chairs). The user stores are arranged in the order all can agree on and as things are moved around, removed or added scissors are used and new stories are written on pieces of paper. This hands-on way of working is greatly appreciated.
At the end of the session, the original PowerPoint file is updated to document what’s on the conference table.
A PowerPoint file with 200 slides is huge, so there is a natural desire to keep the number of slides/stories to reasonable number. Also, the wall where the stories are posted and the conference table used in the grooming sessions make natural boundaries for the size of the backlog.
The release planning is illustrated in the product backlog by inserting head line slides with titles like ”Sprint 23”, ”Sprint 24” etc. The slides following ”Sprint 23” contain the user stories planned for that sprint, until the next head line slide. Normally we plan three sprints ahead and after that we have a head line slide ”Bad hair day” (referring to the fact that the last part of the backlog in not groomed very well).
On our wall where we post the user stories, each forthcoming sprint is represented by a column of user stories. This makes it very easy to see when a particular user story is planned to be released.
What about attachments and additional documents?
Well, you can paste almost anything into a PowerPoint slide – and we do. Sure it turns out really tiny because we have a limited space for additional info), but in MS Office all information from the original document is preserved when you paste into another document, so usually you can see all the details by double clicking on the pasted item and zooming.
So far, this scheme with PowerPoint has worked really well for us. It’s a nice mix of working with physical items (the wall and the conference table) and being able to share with people in other locations (wiki link to Subversion) and finally we have one indisputable original with versioning thanks to the version control system.
We haven’t let go of Trac completely though. We don’t use Trac for the product backlog, but for the sprint backlog. When the sprint starts each user story in the sprint becomes a ticket in Trac. We like the traceability we get when we check in code in Subversion with reference to a Trac ticket. We can see exactly what code changes each user story caused. And of course we use Track for bug reports and team wiki as well.
