https://twitter.com/Scrumartikelen
5 Ways to improve daily scrums
- Be punctual
- Late penalities
- No meeting rooms
- Visualize success
- Invite the boss
https://www.youtube.com/watch?v=sFDLO4DiPFk
A Jira project is a collection of issues.
Every issue belongs to a project
Each project is identified by a Name and a Key
Project Key is appended to each issue associated with the project
Issue is the building block of the project.
eg:
- bug
- task
- user story
- support ticket
- ...
Component
- Components are sub-section of a project
- Components are used to group issues within a project to smaller parts
EPIC
Large body of work, contains stories
STORIES
Smallest unit of work, also known as a task
VERSION
The release of software to the customer
SPRINT
Iteration where team does the work
By working with these vehicles, software teams are able to organize their work and break it down into do-able parts, so they can prioritize customer feedback and change from the original plan of the project without feeling like the walls have crumbled around them.
Epic vs Story
Epics are larger bodies of work that stories roll up into. An epic can span across multiple sprints and versions. Versions are different from epics, because they are a point in time where software is released to the customer. A version might contain multiple epics. Epics help teams create hierarchy and structure. Stories help teams keep track of specific details for the task at hand and can be broken down into sub-tasks.
http://www.agilemodeling.com/artifacts/userStory.htm
Important considerations for writing user stories:
- Stakeholders write user stories. An important concept is that your project stakeholders write the user stories, not the developers. User stories are simple enough that people can learn to write them in a few minutes, so it makes sense that the domain experts (the stakeholders) write them.
- Use the simplest tool. User stories are often written on index cards (at least when your project team is co-located). Index cards are very easy to work with and are therefore an inclusive modeling technique.
- Remember non-functional requirements. Stories can be used to describe a wide variety of requirements types.
- Indicate the estimated size. It includes an estimate for the effort to implement the user story. One way to estimate is to assign user story points to each card, a relative indication of how long it will take a pair of programmers to implement the story. The team then knows that if it currently takes them on average 2.5 hours per point.
- Indicate the priority. Requirements, including defects identified as part of your independent parallel testing activities or by your operations and support efforts, are prioritized by your project stakeholders (or representatives thereof such as product owners) and added to the stack in the appropriate place. You can easily maintain a stack of prioritized requirements by moving the cards around in the stack as appropriate. You can see that the user story card includes an indication of the priority; I often use a scale of one to ten with one being the highest priority. Other prioritization approaches are possible – priorities of High/Medium/Low are often used instead of numbers and some people will even assign each card it's own unique priority order number (e.g. 344, 345, …). You want to indicate the priority somehow in case you drop the deck of cards, or if you're using more sophisticated electronic tooling. Pick a strategy that works well for your team. You also see that the priority changed at some point in the past, this is a normal thing, motivating the team to move the card to another point in the stack. The implication is that your prioritization strategy needs to support this sort of activity. My advice is to keep it simple.
- Optionally include a unique identifier. The card also includes a unique identifier for the user story, in this case 173. The only reason to do this would be to do this is if you need to maintain some sort of traceability between the user story and other artifacts, in particular acceptance tests.
What is an epic?
An epic is a large body of work that can be broken down into a number of smaller stories
Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point.
What is an themes?
A theme is a collection of related user stories. For example, for a university registration system there might be themes around students, course management, transcript generation, grade administration, financial processing.
Themes are often used to organize stories into releases or to organize them so that various subteams can work on them.
https://www.youtube.com/watch?v=RaaBrPCo_Mw
Scrum in 7 steps by productivity game
1> Populate a backlog of all the things need to do in story format: who ... what ... why ... (prioritize the user story) done by po(product owner)
2> Estimate relatively: Fibonacci sequence 1,2,3,5,8,13, ...
3> Plan sprint(2 weeks) eg how many points stories can be done in this sprint. The points are educated guess sprints by sprints. It will be less accurate in early sprints, but more accurate in later sprints.
4> Make work visible : make scrum board
Eg: to do column, in progress column, resolved column
note: backlog column has all predefined user stories, these are might not in this sprint
5> Daily standup: led by scrum leader
- what we did yesterday?
- what will do today?
- what obstacles we have? any blocks?
6> End of sprint, demo
get feedback from user
7> retrospective
- what went well?
- what not well?
- what need to be improved?
Insights from Scrum by Jeff Sutherland from productivity game:
No comments:
Post a Comment