Presentation talking about a model for agile business development using SCRUM -type of approach (i.e. learning from the best practices of software development).
2. Background
• Roots in agile software development, adjusted for
business development
• In addition to HW / SW development used in marketing
and other types of project management type of
activities
• Will result
– Agility in business development
– High throughput in results
– Predictability of progress (after a 3‐4 sprints)
– High awareness of the situation and goal alignment among
the team members
3. Special roles
• Business owner
– Typically the CEO or VP of Business Development
– Prioritizes the backlog
– Defines the overall direction of the team, motivates it
with elevating goals
• Scrum master
– Coach and ”protector” of the team
– Takes the responsibility of the scrum process it self
– Has the responsibility to solve the obstacles aroused
by the team members
4. Stories and tasks
Stories Tasks
• A practical story of what needs to • Ideally as concrete as possible with
get achieved with clear business clear owner
value – Everyone should understand clearly
• Measured in complexity (not hours) what needs to be done
– Use planning poker to determine • Optionally: measured in complexity
• Prioritized based on ease of • If task ends up being complex make
achieving and business value a story instead
– Must have, should have, could have,
will not have
• Are split to tasks for actual
execution
• Ideally should not span over sprints
(i.e. needs to be achieved within a
week)
5. Releases and sprints
Releases Sprints
• Roughly month long super • Roughly week long planning
cycle of sprints cycle
• Should result important • Each should have a clear
milestone(s) / goal(s) goal
• Starts with planning • Starts with planning
weekend meeting
– Combined review, • Ends with review and
retrospective and planning retrospective meeting
meetings, as well as bonding
• Review with all the stake • Review with business
development team
holders
6. Meetings
• Planning
– To plan, describe, prioritize and task the stories
– To plan the sprint (including the team comitment)
• Review
– To review the completed stories of previous sprint (do they meet
acceptance criteria)
• Retrospective
– To give and discuss performance related feedback
– To improve the overall process
• Standup
– To make sure everyone knows where the team is (information
diffusion)
– To check: 1) What was done yesterday, 2) what will be done today and
3) are there any obstacles the way
8. Sprint
Notes:
• Typically either weekly or bi‐weekly cycle, each sprint starts with planning (0.5‐1h) session where stories for
the sprint are prioritized and tasked, sprints end with review meeting (0.5‐1h) completed stories are reviewed
and retrospective meeting (1h) where team goes through the week and gives performance feedback
• Each morning there’s a short (15min) standup meeting (no chairs to keep it short), no problem solving, only
three questions: What did you do yesterday, what will you do today and are there any obstacles on your way?
9. Planning poker
• Complexity cards with points: 1, 2, 3, 5, 8, 13 ,
20, 40, 80, 100
• Everyone shows the card representing the
complexity of the story simultaneously
• If not the same values, lowest and highest
showing cards give their justification for their
estimates
• Repeated until consensus achieved
10. Other tips
• SCRUM is a team effort
– Team decides the volume of commitment
– Team works together to achieve it (what ever it takes)
• Effort / requirements should not change during each sprint (focus
needed)
– Use sandbox for new ideas
• TinyPM is a good tool also for business development SCRUM
• To slim down for lower volume of activities monthly sprints can be
used
– No daily standup meetings Weekly meetings instead
– No definitive release cycle
– Planning weekends for review, retrospective and planning meetings