Posts tagged Scrum
SCRUM blog series part 3: What features do the users want?
02 years ago
in Scrum, Uncategorized
In my journey towards a succesfull SAP BusinessObjects BI4 implementation using SCRUM I’ve got some new experience I’d like to share. As a functional lead for my current SAP BusinessObjects BI4 project, I’m responsible to gather the business requirements and to facilitate in building the product backlog.
Which steps have we gone through?
1. Set up a requirements meeting
2. Build the product backlog
3. Play SCRUM planning poker
4. Prioritize the product backlog items
1. Set up a business requirements meeting
I’ve put together a client specific slide deck that explains the basic concepts of using user roles, personas and writing down requirements in user stories. As a source of inspiration I used the Mountain Goat site. This is truly a great source for SCRUM related information and best practices. Next, I invited the key users for the project to join the requirements meeting. I guided them through the principles of user roles, personas and user stories and moved all chairs out of the room. Stand-up time!
The personas tell a lot about a user. What is his background? Is he experienced with BI and related systems? What are his main frustrations in the current situation? What are his main sets of steering info? Are there specific KPI’s he needs to realize? How does information analysis fit in his business processes? Let your users mirror themselves with the personas. Do they describe the user roles correctly? Is the level of detail for the desired information correct? Are the main measures right? Do they recognize the main challenges and issues for their specific persona? If so, hand over the cards and let them write down their requirements in user stories.
A user story describes a requirement in a short sentence.
“As a <role> I want to <requirement> so that <benefit>.”
For example: “As a Manager I want to have a dashboard with colored alerts as soon as my costs are above budget so that I’m able to notify this real quick.”
A couple of tips:
- You’ll notice that people might find it difficult to get started so help them along with some pre-defined user stories so that they will get inspired
- Be aware that they start writing down the user stories as soon as they start sharing requirements because otherwise you’ll forget and that wouldn’t be necessary
- Group user stories per user group to keep the overview
- Add a “General user” for user stories that are relevant for (almost) all users
- Use sub-user stories to write down the deeper level of detail
- Let your key-users write down the user stories by themselves. That way they’ll be more actively involved and pushed to think how they can put their light bulb (idea) into words (user story)
- If users allready have in mind how the BI solution (e.g. Dashboard) should look like, invite them to make a raw sketch and add this to a user story
- Bring along a list of possible measures and dimensions
- Challenge your users about the level of detail for measures and dimensions (e.g. Country, state, city)
- The right level of detail is the level from which the developer knows what he needs to build
- Give users the option to prioritize requirements into “nice to haves” and “must haves”. This way it’s easier for the product owner to prioritize in the end
2. Build the product backlog
After a succesfull requirements session it’s time to build the product backlog. The product backlog is your total list of requirements / features that are requested by your future users. I can highly recommend to put some kind of structure. If you haven’t got a specific SCRUM tool available, you could use a hierarchical tree map.
In this tree map you could use the following hierarchy structure:
Level 1. Project name
Level 2. Available user roles
Level 3. Requirements divided into BI products (dashboards, interactive reports, etc) or specific features
Level 4. Specific requirements per BI product (dimensions, measures, filters, graphs, etc) or feature
Here is an example:
A couple of tips:
- Start organizing user stories per user role
- Group requirements by requested BI products (dashboards, interactive reports, etc)
- Discuss about the exact meaning of user stories with your SCRUM team members to have a general understanding
- Invite your key users to see and discuss the result after you’ve built your first version of the product backlog
- A product backlog is a dynamic document, it’s “never” finished
3. Playing SCRUM planning poker
You’ve got your product backlog worked out and you’re ready to play some SCRUM planning poker. The main goals of SCRUM planning poker are that all SCRUM team members gain the same understanding of the underlying requirement of a user story and that they agree on how much effort it will be to realize (complexity & time).
Every SCRUM team member receives a card deck with special SCRUM planning poker cards. Each card has a number printed on it. Your card deck could consist of, for example, cards with a 1, 2, 5, 8, 15, 50 number in it.
These points are meant to define how many effort the realisation of a user story would be, with the complexity and amount of time, taken into account. Remember that all points are relative and do not stand for hours, days, etc. The first thing you have to do is to “calibrate” your rating. For example, decide that the ability to display and save a text box under a graph in your dashboard is 5 points. From here on, you’ll start comparing the complexity of the other requirements to this first 5 point requirement.
A couple of examples:
“As a manager I want my dashboard to display an alert if the actual costs are above budget so that I’m able to notify this real quick” > Quite easy, standard functionality, so 2 points
“As a manager I want to be able to drill down from my dashboard into a ad-hoc analysis environment, in which all my dashboard variables and filter settings are included so that I can continue my analysis.” > A bit more complex, but still standard functionality (Open document statement in SAP BO) so 5 points.
Now every requirement will be rated through the poker game. An important rule is that everyone throws their point estimate card on the table at the same time. This way, you won’t be influenced by others and interesting discussions can arise. It’s possible that the “dashboard alert” requirement gets 15 points by a colleague because he doesn’t know the functionality of the available tooling or that he thinks the alert should be sent to a mobile phone for example. If you see that there is quite a difference between the rating of a specific requirement, just put it on the table and discuss about it. You can always check back with the user to ask him what he exactly meant. There are also card decks with a question mark in it. You can throw the question mark on the table if you don’t understand the user story.
Some tips:
- Everyone must throw cards on the table at the same time
- Discuss about a requirement if there is a great difference in the assigned amount of SCRUM points (e.g. 2 versus 15)
- Go back to your users if you don’t know what he exactly meant (question mark cards)
- Let the SCRUM master time-box the poker game
- Let the SCRUM master facilitate the poker game
- Plan enough time for the planning poker session
- Make notes of assumptions you’ve made for a specific low or high rating
- If sketches of dashboards / reports are available from your requirements session, use them during your poker session
- Over time, you’ll be able to give a more accurate point estimate per requirement because you’ll get acquainted with the technology
4. Prioritize the product backlog items
After you’ve played SCRUM planning poker you know what the requirements are and how much effort it (approximately) will be to realize them. Now it’s time for the product owner to set priorities.
Because you’ve organized your product backlog nicely into user roles with underlying requirements and specific BI products, it’s easy for the product owner to set priority to products/requirements he wants to be realized first. It can also help to look at the priority the key users assigned to the various requirements. If it turns out that a “nice to have” requirement is 50 points and a almost similar “must have” requirement is 5 points, it’s quite easy for the product to choose the “must have” item instead.
Next to that, if there are two almost similar “nice to have” requirements but have a total different rating (2 versus 15) it can also help to choose which one to take into the next sprint. An example of 2 versus 15 points could be the ability to comment on your dashboard in mail (2 points) versus the ability to comment on your dashboard in the dashboard itself with the ability to save and reload the comment (15 points).
The SCRUM team must make an estimate of how many SCRUM points they can realize during one sprint. This will force the product owner to focus on those requirements that fit within this given bandwith.
Some tips:
- Over time, you’ll be able to give a more accurate estimate of the amount of SCRUM points you can realize during one sprint so don’t be affraid to “best guess” in the beginning
- Help your product owner by adding comments, if applicable on your time estimate
- Explain both the technical and functional differences between requirement 1 and 2 so that the product owner can make the right choices
- Don’t start discussing again, about the estimated amount of SCRUM points of a specific requirement. If it’s a lot of points, it’s probably quite difficult to realize
Concluding bits:
So we finish another chapter in the SCRUM blog series. I hope you enjoyed reading this and feel free to add comments or questions or suggestions for this or future blogs.
Scrum blog series part 2: practical challenges
02 years ago
in Scrum
This is the second Scrum related blog post. It’s been a few weeks since the previous post in which the Scrum essentials were explained.
In the meanwhile I’ve come up some practical challenges in my current SAP BusinessObjects BI4 project.
Let’s go through a couple of them.
The SAP BusinessObjects product suite has more products than Merlin the wizards magic book has spells
In front of you lies the magic book of Merlin. It has so many spells that you can’t think of a situation for which you won’t have a spell. You need to turn a frog into a princess? You want to be able to walk on water? Just pick the right spell and it will happen. It just fixes every possible situation. SAP BusinessObjects of course has a solution for every business intelligence need. But how do you select the proper tool for a (non-specific) business need? There are just so many SAP solutions that finding “the right spell” can be challenging.
Since the current users are used to work only with MS Excel and the SAP BW Analyzer it’s hard for them to imagine which tool would fit best for their needs.
To help and guide into the direction of a SAP BusinessObjects solution, you could define a basic framework which divides all SAP BusinessObjects solutions into just three categories. Roughly said you can speak of dashboarding, interactive reporting and analysis solutions.
Users shouldn’t care about the SAP BusinessObjects product label. Just make sure you’ll get a clear view of the user needs so you can plot it on one of the three main categories. The SAP roadmap will help you to map specific product solutions onto the categories.
If you’re still unsure which tool should be used for which user, take one sprint to prototype a set of requirements in multiple tools. After the sprint, you can let your users decide which solution fits the best to their needs. This way you don’t spend lots and lots of money and time before getting feedback. After just 4 weeks (depending on your sprint planning) you’re able to adjust your tool selection. Sounds great doesn’t it?
Scrum doesn’t care about detailed financial plannings, but your average stakeholder does!
In Scrum you just say that you’ll do a fixed number of sprints, with a pre-defined Scrum team. For example you could choose to do 5 sprints of 4 weeks each, with your Scrum team which consists of 6 team members.
This way it’s quite easy to say how much the project will cost. You can calculate the costs of one FTE (full time employee) and multiply it with the amount of weeks (#sprints * weeks per sprint) with the # FTE’s. Sounds simple? Well it isn’t..
An average project stakeholder / business sponsor wants to know what he will get in return for his investment. But Scrum only says that all team members will work as hard as they can and give there “best effort commitment”. This results into an unsure list of deliverables for the amount of money that is requested. Oops…
This shouldn’t be a problem at all since in more traditional projects you take a best guess of what things will cost. In the end, you’ll never be as accurate as your project stakeholders / business sponsors would have liked to see. It has proved to me that your stakeholders will need some “adjustment time” to get used to this type of financial planning. In the end, your Scrum financial planning will show you exactly what it will cost with a best effort planning of deliverables. With traditional financial planning methods, you won’t know what it will cost and won’t know how the deliverables will look like. You say which one is best..
Batman & Robin can’t beat down only the Joker, there are more crooks in Gotham City
If you’re going to face a challenging project, you’d like to have the best superheroes around. Let’s say Batman and Robin. They know Gotham City, have many experience beating all the bad guys, have some great gadgets like a batarang, and never lose.
Batman and Robin are the best project members you can imagine. Top notch BI experts with an impressive track record full of cleared BI challenges.
All the bad guys are all the BI projects they’ve dealed with earlier.
The great gadgets are their BI specific skills to fix those really challenging technical requirements.
Now since Gotham City is full of bad guys, Batman and Robin will need to fight multiple bad guys at the same. You could fight only against the Pinguin, but then the Joker or 2-face would take over the place. This means that your super hero Scrum team members won’t be available exclusively for your project. This means that determining your sprint velocity (how many Scrum points can you burn during one sprint) is quite difficult. If one week your resources are available the whole week but the next one only 3 days, it’s quite difficult to determine how fast you can burn down those Scrum points in your burndown chart. Claiming dedicated resources for your project might be a challenge, so prepare for this.
How do you define requirements for a visual solution (dashboards, interactive reports) if your users don’t know what’s possible?
Prototyping, prototyping, prototyping. This doesn’t have to be a real challenge. Go back to elementary school. What did you like best? Drawing pictures. Well this is the way to get those requirements out of your users.
Before you start drawing and sketching, get those information needs on the table. What dimensions and key figures would your users like to report on? On which hierarchical level of detail do they want to navigate their report? Should the data be presented on week, month, year? Would you like to see a product, product group, product division? After you’ve got a view on their needs, start drawing. Just make sketches of how the dashboard or report could look like. Where would you put the tables? Where do you like the graphs? Should it be a bar chart or line chart? Where will we put a company logo? Should there be filter boxes available? Do we need to have a legenda? Which color template should we use? You could go through all these questions without just a single hour of tool development time. Just grab a piece of paper and start drawing. This is what we all liked the best, back in elementary school so this is a treat. After you’ve made a sketch, prototype a solution in a development tool with a small dataset. I must confess that prototyping isn’t clearly positioned within Scrum, but for BI projects and solutions, which often have a strong visual component, I’d really advise to prototype before spending expensive development hours in the tools.
The end
This is about it for now. As the project continues, my posts will keep coming. I’ve got a Scrum planning poker session ahead of me so new blog content will arise.
Scrum blog series part 1: Scrum essentials
12 years ago
in Scrum
This is the first of a serie of blog posts on agile development with Scrum.
In this blog post I’ll try to cover the Scrum essentials so you can come up-to-speed with the basic concepts.
In upcoming posts, I’ll jump into more specific details or bumps I’ve run into while using Scrum for SAP BusinessObjects projects.
Let’s get started!
The Agile Manifesto
The Agile Manifesto defines a set of basic principles which should be taken into account when considering developing in an Agile way. If you want a deep dive into the history of the Agile Manifesto and it’s origin, just click the following link.
The basic concept of the Agile Manifesto is written down in the diagram below.
Source: http://hypergogue.net/wp-content/uploads/2010/07/agile-manifesto1.gif
An introduction to what adds value and what doesn’t
I will give you my take on how I see Scrum. For me, Scrum is a development methodology that delivers results quickly in an iterative way, with a focus on user acceptance and involveness, with only the absolute necessary amount of documents and project roles where requirements can change during the project.
You can think of all the 100+ page counting project documents to describe the vision, project organisation, business requirements, functional designs, technical designs, etcetera in the most extreme detail. We all know what happens to these paper tigers when they are let loose on your email address book. They only get quick scanned because no one has time to read it in such detail. Next to that, requirements often change during the project and because the scope is “fixed” you can’t respond fast enough to these new requirements. You’ll need to initiate a “request for change” procedure which will take lots of time, paper and people before the scope and requirements are updated.
Personally I build great amounts of energy by getting things done in the smart way.
Don’t write dinosaur documents that nobody will read.
Don’t act like your busy if you’re not. Even worse, don’t keep other people busy to keep yourself busy!
Don’t think that users fully understand the potential of an application after they’ve seen a 15 minute demo.
Don’t think that requirements are like concrete but accept that they can change during the project.
Don’t think that only a 99% finished application is good enough to show your future users.
Instead of all these things you shouldn’t do, stick to the basics. If you want to sell Hot Dogs, make sure you get some sausages and some bread to put it on. The fancy marketing flyers, website, company clothing, extra hot sauce etcetera will come later. First start with the stuff that really counts so that you can start selling some!
Now we are getting to the core of Scrum. In a short amount of time, you deliver a working piece of software with a clear focus on a set of requirements or features for this sprint. They can change in the next increment. Scrum is the development methodology that supports this process.
What do we need to start a Scrum project?
Only two things:
“The minimum plan to start a Scrum project consists of a vision and a Product Backlog.The vision states why the project is being undertaken and what the desired end state is.”
That’s a relief! No 100+ page project brief, long term planning etc, only the truly necessary thing is a vision and a desired end product, which is called the product backlog.
The famous Scrum process “rat wheel”
We start off with a product backlog. This is a list of things to do. This can be high level requirements, features, qualities, etc which are prioritized (by the product owner). The items in the product backlog are divided in sprint backlog items in which the requirements are described in a bit more detail and which will be realized in one sprint. Often they are described in use cases or user stories. The next step is a sprint. This is the available time period (2-4 weeks) in which a new iteration of the potentially shippable product increment must be delivered. Within this sprint, on a daily basis, a daily Scrum meeting is organised in which the development team looks at the open sprint backlog items and answers three questions.
1. What did I do yesterday?
2. What am I going to do today?
3. Are there any issues?
The heart of Scrum lies in the iteration. The team takes a look at the requirements, considers the available technology, and evaluates its own skills and capabilities. It then collectively determines how to build the functionality, modifying its approach daily as it encounters new complexities, difficulties, and surprises. The team figures out what needs to be done and selects the best way to do it. This creative process is the heart of the Scrum’s productivity.
Scrum roles
Team (apprx 5 members)
The team which does all the work. It’s cross-functional (developers, designers, testers, etc) and, very important, it’s self-organizing. At the end of a sprint, it demos the result to the product owner.
Product Owner
Fully Committed, responsible for ROI, prioritizes the work. He is in between the customer and the team where he walks, talks, negotiates and communicates. Next to this, he accepts or rejects work results.
Scrum Master
Manages and facilitates the Scrum process. If a more traditional project manager is Clint Eastwood, the Scrum Master is James Bond. He eliminates project threats and has a license to kill.
Future blog posts
This was the first blog post on Scrum and Agile development. I hope it gave a clear overview of the essentials of Scrum. In the upcoming blogs I’ll look more into practical issues or challenges I’ve come up with while using Scrum for business intelligence related projects.
I’d like to thank Arnoud Kouwenhoven, for sharing his thoughts on Scrum with me. Arnoud is a certified Scrum Master and can be found on LinkedIn.com
Recent Comments